Oberon space
General Category => Общий раздел => Тема начата: Peter Almazov от Июль 01, 2014, 05:55:37 am
-
Мне часто приходится выступать в двух ролях – в роли разработчика UI, а затем в роли реализатора того, что разработал. На первом этапе рисую эскизы интерфейсов, используя весь свой опыт и знания. Да и люблю я это дело.
Несмотря на честно выполненную работу на первом этапе, в процессе реализации и отладки интерфейс сильно меняется, часто радикально. В сторону улучшения.
Поскольку такое улучшение происходит регулярно, то это наводит на мысль, что держать узкого специалиста по юзабилити и разработке (но не реализации) UI бессмысленно, т.к. он будет выдавать некачественную продукцию.
Рассуждаю как теоретик - я никогда не видел живьем такого специалиста. Видел пару т. н. "бизнес-аналитиков", людей которые не могли программировать. Это были полные дебилы.
У кого какой опыт?
-
То же самое.
Вообще придерживаюсь мнения, что интерфейс просто невозможно сразу сделать правильно. У каждого пользователя свои сценарии работы и тараканы.
-
Вообще же от задачи зависит -- где-то можно тупо генерировать интерфейс, а где-то приходится вылизывать до мелочей вручную...
-
Согласен с Петром.
Кстати, считаю, что кроме интерфейсов также очень востребованы дизайнеры, умеющие напрямую давать HTML/CSS-шаблон.
Очень многое удобно делать сегодня кодом, а не фотошопом. А так - двойная работа.
-
Эмм.. При чем тут фотошоп?
Проектировщик UI не пользуется фотошопом. И средой программирования тоже не пользуется :-) Он описывает систему взаимодействия человека и машины. Возможно примерное расположение GUI-элементов. Но графическим дизайном он не занимается. Не пользуется он и HTML/CSS. Реализацией вообще другие люди делают. А этот человек на выходе дает спеку на UI.
Подобные специалисты, по моему опыту, очень редки и очень круто если такого человека удалось найти. Программисты сами по себе проектируют обычно ужасающие интерфейсы. А дизайнеры/художники (владеющие фотошопом, или там css/html) вообще неюзабельный ужас проектируют.
Собственно у меня перед глазами пример, когда в конторе два человека. Один из них программист, а другой именно вот такой вот спец по юзабилити и представлению данных. И это дает отличный результат, и соответственно профит :-) А работы художника/дизайнера они аутсорсят.
-
Как то у тебя все слишком ровно. Не видел я живых людей, способных на пустом месте сделать хороший интерфейс.
Для хорошего результата нужна долгая и нудная работа непосредственно с пользователем. Анализ реальных сценариев работы у как можно большего числа людей.
И хочу особо подчеркнуть, что нужен анализ реальной работы людей с ПО (которое разрабатывается). Без этого сделать хороший интерфейс практически невозможно.
Т.е. разработка интерфейса это всегда несколько итераций как написал Петр.
И тут проблема курицы и яйца. Чтобы понять как делать интерфейс нужен... интерфейс.
В общем это что-то вроде решения слау методом итераций :D
-
Как то у тебя все слишком ровно. Не видел я живых людей, способных на пустом месте сделать хороший интерфейс.
Для хорошего результата нужна долгая и нудная работа непосредственно с пользователем. Анализ реальных сценариев работы у как можно большего числа людей.
И хочу особо подчеркнуть, что нужен анализ реальной работы людей с ПО (которое разрабатывается). Без этого сделать хороший интерфейс практически невозможно.
Т.е. разработка интерфейса это всегда несколько итераций как написал Петр.
И тут проблема курицы и яйца. Чтобы понять как делать интерфейс нужен... интерфейс.
В общем это что-то вроде решения слау методом итераций :D
Ну дык оно и не за одну итерацию делается. Но анализом всего этого занимается не программист, а проектировщик интерфейса.
Ну и ты учти, что это всё не про ынтырпрайз-заказное или там корпоративное ПО (к которому все решения на 1С например вполне относятся). Это ПО для широкой аудитории, причем поговорить с ней ты, грубо говоря, не можешь, то есть заказчика в корпоративном смысле, тут нет. И ТЗ от него нет. И вообще это ты еще должен как-то доказать и убедить аудиторию что твоё поделие им нужно :-) В таких условиях грамотный приятный, понятный не перегруженный интерфейс начинает играть ключевую роль. Особенно когда приложение - оно под OS X. В такой ситуации выделение порядка 50% ресурсов на проектирование интерфейса, а еще 25 процентов на его реализацию - имеет смысл, и иначе там просто не выжить.
-
ПО для широкой аудитории, причем поговорить с ней ты, грубо говоря, не можешь, то есть заказчика в корпоративном смысле, тут нет.
ОК, а кто тогда сказал, что интерфейс хороший?
И я таки подозреваю, что Петр под интерфейсом имел в виду именно интерфейс с которым человек 8-10 часов в сутки работает.
Интерфейс для оператора, который за день видит, анализирует и вбивает тысячи цифр, и интерфейс для порносайта требуют совершенно разных усилий. Говорить о сложности второго случая просто смешно. Тогда как первый это адъ.
-
ПО для широкой аудитории, причем поговорить с ней ты, грубо говоря, не можешь, то есть заказчика в корпоративном смысле, тут нет.
ОК, а кто тогда сказал, что интерфейс хороший?
А с плохим интерфейсом никто не то что не купит, даже и пробовать не станет. А интерфейс, по крайней мере у них, получается хорошим хотя бы потому, что их приложение уже используется как пример в соответствующей тематической литературе (по юзабилити, представлению данных и так далее) :-)
И я таки подозреваю, что Петр под интерфейсом имел в виду именно интерфейс с которым человек 8-10 часов в сутки работает.
Интерфейс для оператора, который за день видит, анализирует и вбивает тысячи цифр, и интерфейс для порносайта требуют совершенно разных усилий. Говорить о сложности второго случая просто смешно. Тогда как первый это адъ.
Порносайт это отдельная категория, как понимаешь. И привлекают туда не удобным интерфейсом, а контентом :-)
Да, и про какую сложность говорим? Мне доводилось принимать участие в разработке интерфейса и для диспетчерского пульта системы САУ ГМК (точнее нескольких цехов ГМК) для ПХГ, так и интерфейса для пользовательсткого приложения где функционала и данных сильно меньше (в итоге там было то ли 3 то ли 4 кнопки). И я затрудняюсь сказать что было сложнее сделать. Склоняюсь что второе было сложнее чем первое. По ряду показателей.
-
Не не не. Это справедливо только при большом выборе и здоровой конкуренции. Вот взять тот же 1С. Нравится тебе или нет, а придется с ней работать, если ты бухгалтер. Ибо монополия.
Или там Windows. Или Office. Или ...
-
Да, и про какую сложность говорим? Мне доводилось принимать участие в разработке интерфейса и для диспетчерского пульта системы САУ ГМК (точнее нескольких цехов ГМК) для ПХГ, так и интерфейса для пользовательсткого приложения где функционала и данных сильно меньше (в итоге там было то ли 3 то ли 4 кнопки). И я затрудняюсь сказать что было сложнее сделать. Склоняюсь что второе было сложнее чем первое. По ряду показателей.
Я говорил про то, что сложно сделать интерфейс оператора так, чтобы 9 из 10 операторов были довольны результатом. Как правило разработка интерфейса начинается с недовольства всех 10...
-
Да, и про какую сложность говорим? Мне доводилось принимать участие в разработке интерфейса и для диспетчерского пульта системы САУ ГМК (точнее нескольких цехов ГМК) для ПХГ, так и интерфейса для пользовательсткого приложения где функционала и данных сильно меньше (в итоге там было то ли 3 то ли 4 кнопки). И я затрудняюсь сказать что было сложнее сделать. Склоняюсь что второе было сложнее чем первое. По ряду показателей.
Я говорил про то, что сложно сделать интерфейс оператора так, чтобы 9 из 10 операторов были довольны результатом. Как правило разработка интерфейса начинается с недовольства всех 10...
Угу. И это намного проще чем проектировать пользовательское приложение.
-
Что есть пользовательское приложение?
-
Как то у тебя все слишком ровно. Не видел я живых людей, способных на пустом месте сделать хороший интерфейс.
Вот тоже, плохо верится в такую идилию. Во всяком случае, возникает куча вопросов к valexey_u.
Я тут накидаю, может на какие-то получится ответить.
Он описывает систему взаимодействия человека и машины. Возможно примерное расположение GUI-элементов. Но графическим дизайном он не занимается. Не пользуется он и HTML/CSS. Реализацией вообще другие люди делают. А этот человек на выходе дает спеку на UI.
Самый главный вопрос – как выглядят спеки на UI?
Как описывается динамика, допустим, условия, при которых какой-то элемент enabled/disabled/hidden и т п.?
Сколько времени занимает итерация? Как это выглядит на практике? Cкажем, надо исправить какую-то мелочь. А после исправления видно, что получается плохо, надо переделать.
Может ли идеолух сам исправлять мелочи?
Проявляет ли какую-либо инициативу реализатор? Есть ли у него какая-либо серьезная подготовка в юзабилити?
-
Да, и про какую сложность говорим? Мне доводилось принимать участие в разработке интерфейса и для диспетчерского пульта системы САУ ГМК (точнее нескольких цехов ГМК) для ПХГ, так и интерфейса для пользовательсткого приложения где функционала и данных сильно меньше (в итоге там было то ли 3 то ли 4 кнопки). И я затрудняюсь сказать что было сложнее сделать. Склоняюсь что второе было сложнее чем первое. По ряду показателей.
Я говорил про то, что сложно сделать интерфейс оператора так, чтобы 9 из 10 операторов были довольны результатом. Как правило разработка интерфейса начинается с недовольства всех 10...
Грамотное проектирование ведётся с позиции эргономики, а не с позиции "нравится/не нравится". Потому что эргономика объективна.
-
Для хорошего результата нужна долгая и нудная работа непосредственно с пользователем. Анализ реальных сценариев работы у как можно большего числа людей.
У любой программы есть цель, с которой она делалась. И есть только два варианта использования программы: в качестве инструмента решения задачи, для которой программа создавалась, и неправильный. Заниматься "долгой и нудной работой непосредственно с пользователем", чтобы ему было удобно использовать программу по второму варианту, не считаю целесообразным. А для первого варианта полная информация, которую вы хотели бы получить от пользователя, у вас уже есть: он хочет решить задачу, а у программы цель - это решение этой задачи.
Если же приходится для первого варианта производить опрос жертв, то это лишь значит, что разработчик не понимает, какую программу он делает, что она должна делать. И интерфейс здесь - самая меньшая из проблем. И долгая работа с пользователем - это как крик отчаянья: "да что же я, чёрт возьми, делаю?! Скажите мне!". А причина проста: не разработана предметная область. Такую разработку может дать либо аналитик, либо носитель предметной области, который, в свою очередь, когда-то получил её от того, кто провёл анализ. И если на анализ нет времени у того, кто пишет программу, то у оператора АРМа его нет и подавно - он работает, и ему некогда. В общем случае. И его опрос принесёт информацию, полезность которой крайне ограничена.
-
Не знаю о чем вы. Я же описал как оно в реальности.
Фантазии не интересны.
Т.е. то что вы описали в теории правильно. Но на практике так не бывает (или бывает, но крайне редко)
А для первого варианта полная информация, которую вы хотели бы получить от пользователя, у вас уже есть: он хочет решить задачу, а у программы цель - это решение этой задачи.
Сразу видно, что у вас мало опыта в разработке различных интерфейсов. :)
Могу задачку подкинуть из реальной жизни. Посмотрим, что вы сможете предложить без той самой долгой и нудной работы с пользователем.
ps Специалистов по предметной области отродясь не видал. Возможно они существуют, но в реальности в предметную область приходится вникать программисту (руководителю, а частенько и кодеру).
-
ps Специалистов по предметной области отродясь не видал. Возможно они существуют, но в реальности в предметную область приходится вникать программисту (руководителю, а частенько и кодеру).
Хорошие специалисты по предметной области сами пишут себе ПО. Я придерживаюсь точки зрения, что программирование - это общетехническая дисциплина, такая же как мамематика или физика для инженеров. (Это, конечно, не означает, что программисты не нужны)
-
Программирование - это общетехническая дисциплина, да. Но не нужно забывать, что есть совершенно конкретная профессия "программист".
И есть большая разница между программистами "для себя" и теми кто работает в этой сфере.
Чтобы хорошо программировать, нужно (как минимум) заниматься этим 8 часов в сутки 5 дней в неделю.
-
Сразу видно, что у вас мало опыта в разработке различных интерфейсов. :)
Зато есть большой опыт в лечении геморроя, возникшего при разработке интерфесов тем способом, который Вы описали.
-
Можно подробнее?
-
Нам давали задание с указанием, например, какая кнопка где должна располагаться и что должна делать, но официально мы не знали что должна делать сама форма. А та информация, которая была неофициальной, была и неточной (и неполной). Мы всё делали. После этого, нашу работу смотрели, и приходили к выводу, что там как-то мало всего и чего-нибудь ещё докидывали. Дело не в фичевании: просто те, кто давал задание, не всё до конца понимали. Докидывание производилось беспорядочно и в разное время (не обязательно мысль о том, что сделанного недостаточно, приходила сразу). Но поскольку мы не знали общий фронт работы, то места для последующих вставок не могли предугадать: наш код шёл одним потоком. И, по-хорошему, после каждого нового серьёзного добавления требовалось бы переписать всё заново. Но, понятное дело, нам на это времени не давалось. И мы делали сумасшедшие вставки, которые отладить толком нельзя было. Баги, в основном, нам присылали пользователи, поскольку об адекватном тестировании нельзя было и говорить: проверять должен тестировщик ручками, комбинаций огромное количество (навскидку - больше ста) , интерфейс отзывается не сразу (поэтому акт тестирования очень утомлял и мог сильно снижать качество тестирования). А виноватыми почему-то всегда оказывались мы.