Нет, я все понимаю. Просто топик был про то, как сэкономить время на переводе взгляда от одного поля к другому, но… на секундочку, такие как я не могут не отрывая взягляда от экрана заполнить всю форму сверху. :) я не могу точно.
Для меня важнее было бы удообно структурировать поля (заголовок + поле ввода) чтобы сэкономить время на позиционирование моего взгляда после клавиатуры — каждый раз как первый раз, последовательность перехода от поля к полю не важна.
Плохо поступаю наверное, но для каждого вводимого поля я не только глаза вправо-влево двигаю, но еще и вниз на клавиатуру, а потом снова хватаюсь за мышку, чтобы перейти к следующему полю. Мне уже ничего не поможет… :)
Дорого. 80 — 500 т.р. Нет, поймите меня пожалуйста правильно. Я сразу же подумал применительно к своей работе. Дорого в моем случае. Вот для чего действительно классно применять данную технологию, так это для проверки полиграфии перед печатью большого тиража.
В общем-то у технологии отличное будущее если только со временем удастся снизить ее стоимость (тем самым увеличив базу респондентов, или повысив итеративность изменений в дизайне). Это как с рентген-снимками у стоматологов. 10 лет назад делали один на пленке перед лечением. И то, было долго и дорого. Теперь при чистке и пломбировании многочисленных каналов сделают 3-5 с меньшей дозой облучения и уже цифровые.
:) я дизайнер. Для того, чтобы ответ был профессиональным, надо кого-то другого спросить.
Я очень люблю асинхронный интерфейс. Вы «заказываете» какую-то «тежелую» работу (например, нажали на кноку отфильтровать по модулю 'foo.exe'), интерфейс должен быть немедленно готов к следующему вашему «заказу». Возможно, вы тут же передумаете и сделаете фильтрацию по модулю 'bar.exe', тогда предыдущая аналогичная работа должна быть отменена. Очень часто в моей практике программисты недооценивают время исполнения казалось бы простой обработки нажатия на кнопку. Или на их быстрой машине работает все быстро, либо заказываемая по нажатию работа специфично маленькая. Интерфейс подвисает. Через 20 секунд начинаешь волноваться. Через пару минут тянешься снять весь процесс. Ну, вы знаете…
«синдром второго продукта» в двух словах это ситуация когда в «первом продукте» ты сумел ограничить полет своей фантазии, а во втором никак не можешь. У нас столько отличных идей и так хочется все-все сделать, но к сожалению «второй продукт» должен быть сделан в срок и с высочайшим качеством. Нужно сделать хорошо, но меньше. Это проблема :)
Больше всего времени тратится на координацию идей. Если ваша команда из 10 человек, вы достигаете договоренности за час. Если из 20, то за рабочий день. Если из 100, то можете не достигнуть договоренности никогда. Моя работа состоит в быстрой визуализации. Да, бывает что я «угадаю» с первой же картинкой — все посмотрят и скажут, что это то, что надо. Бывает наоборот, проходим долгие 15-20 итераций, а потом через месяц все равно все выбросим. Финальный результат бывает что сильно отличается от начальной идеи, это нормально. Хотя, недавно я пересматривал самые первые эскизы, почти все от первых идей будет в продуктах. На конкурентов (партнеров) смотрим регулярно и пристально :)
Насчет сложностей с реализацией долго думал как ответить. Кратко — нет, больших проблем не было. Я стараюсь рисовать только feasible things. Конечно бывает, что та или иная операция на практике оказывается долгой (объективно долгой, например перелопатить 2-3Gb данных и выдать результат 30 раз в секунду сложно). Стараемся выкрутиться как-то, но без кнопок «Update» (терпеть не могу кнопки Update/Refresh и т.д.). В Intel работают очень хорошие программисты, рано или поздно, у нас все получается.
Мы пишем «монстров» которые имеют на Windows и Linux совершенно одинаковые user interfaces. Монстров, в том смысле, что та или иная операционная система дает определенные преимущества (и мне, как дизайнеру), но приходится себе отказывать и не использовать эти преимущества. Наши «монстры» не всегда выглядят нативно в конкретной операционной системе или среде разработки. Они пользуются неким кросплатформенным минимумом. Ресурсов на то чтобы писать два (или четыре) совершенно различных frontend`а у нас просто нет. Каждый программист задумывается о том, как вот этот контрол будет выглядеть под MS Visual Studio и в Ubuntu. Вы понимаете куда я клоню, да? Остается С++, и WxWidgets (не будем обсуждать недостатки или преимущества). Код компилируется Intel C++ Compiler (и Майкрософтовским тоже), я так понимаю для того, чтобы код был менее компиляторо-зависимым. Внутри продуктов активно используется потоковость и в частности Intel TBB (в том числе для «отзывчивого» UI, не держим GUI thread — перекладываем time-consuming операции на другие потоки). И конечно же при разработке мы пользуемся собственными разработками — проверям утечки памяти и корректность параллельного кода при помощи Intel Parallel Inspector или Inspector XE, оптимизируем производительность при помощи Intel VTune Amplifier XE.
А, вы про малое разрешение в целом… Да, конечно, это учитывается при дизайне.
Про масштабирование изображений: да, мы выбираем подготовленную иконку из ряда (16х16, 24х24, 32х32) под конкретный размер шрифта в системе. Не всюду получается это сделать (некоторые продукты очень большие, они пишутся разными людьми), но, например Intel Parallel Advisor полностью следует этому принципу.
Это, скажу вам, мучительнейший процесс. С одной стороны мы пытаемся начать с чистого листа. Но очень быстро приходим к проверенным временем решениям. С другой стороны есть очень серьезные наработки, которые представляют собой более или менее компактные «блоки» (некие куски продукта, которые хорошо зарекомендовали себя в предыдущих версиях. Такие куски обычно отполированы в боевых условиях представителями многих именитых компаний). Часто такие куски невозможно логично сгруппировать в единый продукт. Приходится чем-то жертвовать, или идти на компромисы. Спросите пожалуйста конкретней, на каком либо примере из Intel Parallel Studio, я вам расскажу историю :)
ой нет, каждый, так сказать, «поступает как может». Кем я точно не хочу быть, так изрекателем истины в первой инстанции. Описанный подход более или менее работает в команде 100+ человек расположенной в 4 частях света при наличии одного дизайнера. Kigorw, будьте добры, раскойте в деталях, что вы имели в виду?
Некторый элемент «насилия» над профессиональным пользователем неявно подразумевается (Если продукт дает ценный результат, пусть даже в убогой форме, то пользователь продолжит им пользоваться, даже неудобным). Я лично хотел бы сохранить на первом месте ценность информации, пусть даже в ущерб способу ее представления. С другой стороны не хотелось бы злоупотреблять терпением наших пользователей. Баланс… как и во всем.
Ноутбуки дают преимущество по горизонтали… Да, мы думали над этим. Для больших EBS-based результатов с большим количеством столбцов это очень ценное преимущество. Мы думали над этой проблемой несколько шире. Я вспоминаю одну usability testiing session, когда испытуемый первым делом развернул экран на 90 градусов (портретное расположение экрана) и весь мой дизайн поплыл. Представляете? :)
Только не смейтесь, в Photoshop. Я просто знаю этот продукт с 90х, и он мне привычнее всего. В Интеле, я один из немногих («гордый обладатель») лицензионной копии. Вообще, я думаю, инстремент может быть любым, лишь бы результат говорил сам за себя, и сделать mock-up можно было бы за несколько минут.
Баланс хрупкий, согласен. Эта проблема вечная как мир. Внутри комманды мы договорились сделать Intel Parallel Studio как можно более простой и дружелюбной для пользователя, пусть даже ущемляя наши технические возможности. Зато Intel Parallel Studio XE будет использовать весь спектр наших последних технологий, пусть даже не всегда будет немедленно понятно как этим пользоваться. Эта договоренность внутренняя. Несколько раз мы пытались изменить сами себе — сделать «первую студию» более технически подкованной, а «вторую» более понятной. Но в целом слово сдержали. Считаю ли я результат удачным? Да. Есть оговорки, но разрешите их оставить при себе. Были ли сложности? Да и много. Например известный синдром «разработки второго продукта». Если интересно, то распросите меня дальше :)
да, я в отпуске, но постараюсь отвечать сегодня и завтра (в пятницу). Мне самому очень интересно. Пожалуйста, задавайте ваши вопросы. К сожалению, начиная с субботы я уезжаю туда, где компьютеров нет.
Для меня важнее было бы удообно структурировать поля (заголовок + поле ввода) чтобы сэкономить время на позиционирование моего взгляда после клавиатуры — каждый раз как первый раз, последовательность перехода от поля к полю не важна.
Плохо поступаю наверное, но для каждого вводимого поля я не только глаза вправо-влево двигаю, но еще и вниз на клавиатуру, а потом снова хватаюсь за мышку, чтобы перейти к следующему полю. Мне уже ничего не поможет… :)
В общем-то у технологии отличное будущее если только со временем удастся снизить ее стоимость (тем самым увеличив базу респондентов, или повысив итеративность изменений в дизайне). Это как с рентген-снимками у стоматологов. 10 лет назад делали один на пленке перед лечением. И то, было долго и дорого. Теперь при чистке и пломбировании многочисленных каналов сделают 3-5 с меньшей дозой облучения и уже цифровые.
Я очень люблю асинхронный интерфейс. Вы «заказываете» какую-то «тежелую» работу (например, нажали на кноку отфильтровать по модулю 'foo.exe'), интерфейс должен быть немедленно готов к следующему вашему «заказу». Возможно, вы тут же передумаете и сделаете фильтрацию по модулю 'bar.exe', тогда предыдущая аналогичная работа должна быть отменена. Очень часто в моей практике программисты недооценивают время исполнения казалось бы простой обработки нажатия на кнопку. Или на их быстрой машине работает все быстро, либо заказываемая по нажатию работа специфично маленькая. Интерфейс подвисает. Через 20 секунд начинаешь волноваться. Через пару минут тянешься снять весь процесс. Ну, вы знаете…
Больше всего времени тратится на координацию идей. Если ваша команда из 10 человек, вы достигаете договоренности за час. Если из 20, то за рабочий день. Если из 100, то можете не достигнуть договоренности никогда. Моя работа состоит в быстрой визуализации. Да, бывает что я «угадаю» с первой же картинкой — все посмотрят и скажут, что это то, что надо. Бывает наоборот, проходим долгие 15-20 итераций, а потом через месяц все равно все выбросим. Финальный результат бывает что сильно отличается от начальной идеи, это нормально. Хотя, недавно я пересматривал самые первые эскизы, почти все от первых идей будет в продуктах. На конкурентов (партнеров) смотрим регулярно и пристально :)
Насчет сложностей с реализацией долго думал как ответить. Кратко — нет, больших проблем не было. Я стараюсь рисовать только feasible things. Конечно бывает, что та или иная операция на практике оказывается долгой (объективно долгой, например перелопатить 2-3Gb данных и выдать результат 30 раз в секунду сложно). Стараемся выкрутиться как-то, но без кнопок «Update» (терпеть не могу кнопки Update/Refresh и т.д.). В Intel работают очень хорошие программисты, рано или поздно, у нас все получается.
Про масштабирование изображений: да, мы выбираем подготовленную иконку из ряда (16х16, 24х24, 32х32) под конкретный размер шрифта в системе. Не всюду получается это сделать (некоторые продукты очень большие, они пишутся разными людьми), но, например Intel Parallel Advisor полностью следует этому принципу.
:) наступаю на горло собственной песне. Я же дизайнер в Intel, а не художник. Вот в картине, изивните, я ничего ни для кого менять не стану.
Ноутбуки дают преимущество по горизонтали… Да, мы думали над этим. Для больших EBS-based результатов с большим количеством столбцов это очень ценное преимущество. Мы думали над этой проблемой несколько шире. Я вспоминаю одну usability testiing session, когда испытуемый первым делом развернул экран на 90 градусов (портретное расположение экрана) и весь мой дизайн поплыл. Представляете? :)