Комментарии 73
>чем плохой интерфейс отличается от плохого
Действительно, чем?
Действительно, чем?
«ОК»
Ой, Неткрекер родной ;) Таню, впрочем, не помню.
Очень мелкий текст в презентации.
сделал чуть побольше
Посмотрел, все равно мелко. Поясню свой коммент. Лекция про удобство интерфейсов, а тексты в презентации мелкие, трудночитаемые. Может оператору надо было брать более крупный ракурс или при обработке видео повставлять слайды. Смотреть отдельно презентацию, чтобы понять, что там было на экране крайне не удобно.
Очень милая девушка, смотрел с удовольствием.
Я хочу с ней познакомиться :)
Смотрел с интересом. Однако, всё никак не мог найти синоним «interface», все-таки слово не наше… Судя по тому как это представляли, особенно на примере гамбургера, ведь есть же синоним Русский.
Понимаю, что все так привыкли и т.д., однако
Понимаю, что все так привыкли и т.д., однако
Ну если брать анологию определения интерфейса аппаратного (это устройство сопряжения, например внешних устройств в/в c платой ...), то можно сказать, что интерфейс в ПО — это элемент сопряжения пользователя с программой, который задает правила игры, правила взаимодействия.
Интерфейс — сопряжение.
Интерфейс — сопряжение.
я предпологаю, что interface просходит от interactive face — интерактивное лицо. интерактивный — это основанный на взаимодействии. Другими словами interface — точка взаимодействия. синонимов тут особо в русском языке нет.
Согласен, что однозначных синонимов нет… однако… идите глубже…
поэтому и интересно стало.
поэтому и интересно стало.
«Active» тут, по-моему, не причем, а «face» скорее плоскость, фасад, грань, чем передняя часть головы, а если и лицо, то в переносном смысле. Скорее прямой перевод на русский звучит как «секущая плоскость», «разделяющая грань» имея в виду разделение сложной системы на подсистемы и место их соприкосновения и, да, взаимодействия.
с вашим переводм face — полностью согласен. про «active» вроде ничего не писал :) а «взаимодействие» с которым вы в итоге согласились переводится на английский как «interaction».
Я про interactive, про то, что само слово interface не образовано от interactive. Что они оба начинаются на inter случайность :)
думаю вы правы: dictionary.reference.com/browse/inter-
Междумордие?
Из словаря Longman
interface noun www.ldoceonline.com/dictionary/interface_1
1 the way in which you see the information from a computer program on a screen, or how you type information into the program [↪ GUI]
2 technical the part of a computer system that connects two different machines
3 the way in which two subjects, events etc affect each other interface between
The book deals with the interface between accountancy and law.
4 technical the surface where two things touch each other
interface noun www.ldoceonline.com/dictionary/interface_1
1 the way in which you see the information from a computer program on a screen, or how you type information into the program [↪ GUI]
2 technical the part of a computer system that connects two different machines
3 the way in which two subjects, events etc affect each other interface between
The book deals with the interface between accountancy and law.
4 technical the surface where two things touch each other
Отличная лекция! Таня кстати есть на хабре — lazytanka.habrahabr.ru
Мдаааа… Смотрю ролик и тихо уползаю под стол…
Банкомат выплевывает карточку сразу не потому что банки такие хорошие и заботятся о сохранности денег клиента. Они это делают, чтобы не раздувать штат саппорта и юротделов, в которые будут звонить злобные пользователи, которые умудряются забыть карточку в банкомате. Затраты банка на саппорт и юристов больше, нежели возможные потери от возврата наличности на карточки (чего никто не делает, ясное дело).
Хороший проектировщик должен решать проблемы пользователя, а не повышать скорость, надежность и еще что-то там. Можно спроектировать устройство, которое бы при нажатии на одну кнопку находило бы кошку и проводило тщательный процесс вычесывания шерсти, но оно было бы не востребовано, потому что важен не результат в виде вычесаной кошки, а процесс и удовольствие от процесса.
Когда начались рассказы про предугадывание фотошопом действий и автоматизме в работе с интерфейсами, психика не выдержала…
Таня, извини конечно, но ты рассказываешь про свои эмоции и догадки, основанные на следствиях, но не о причинах.
Банкомат выплевывает карточку сразу не потому что банки такие хорошие и заботятся о сохранности денег клиента. Они это делают, чтобы не раздувать штат саппорта и юротделов, в которые будут звонить злобные пользователи, которые умудряются забыть карточку в банкомате. Затраты банка на саппорт и юристов больше, нежели возможные потери от возврата наличности на карточки (чего никто не делает, ясное дело).
Хороший проектировщик должен решать проблемы пользователя, а не повышать скорость, надежность и еще что-то там. Можно спроектировать устройство, которое бы при нажатии на одну кнопку находило бы кошку и проводило тщательный процесс вычесывания шерсти, но оно было бы не востребовано, потому что важен не результат в виде вычесаной кошки, а процесс и удовольствие от процесса.
Когда начались рассказы про предугадывание фотошопом действий и автоматизме в работе с интерфейсами, психика не выдержала…
Таня, извини конечно, но ты рассказываешь про свои эмоции и догадки, основанные на следствиях, но не о причинах.
Народ, если вы далеки от юзабилити и проектирования, то это не значит, что все остальные такие же как и вы.
Ах да, тут не в почете конструктивная критика, я забыл… Извините.
Ах да, тут не в почете конструктивная критика, я забыл… Извините.
Любите музыку в себе, а не себя в музыке.
Ваши замечания не контраргументы (или), а дополнения (и). Хороший интерфейс решает как задачи пользователя, так и задачи бизнеса. В примере с банкоматом задача бизнеса в снижении нагрузки на службу поддержки (Вы написали), а безопасность, скорость выполнения операции и отсутствие ошибок гарантирует решение задач пользователя (Таня об этом сказала).
Ваши замечания не контраргументы (или), а дополнения (и). Хороший интерфейс решает как задачи пользователя, так и задачи бизнеса. В примере с банкоматом задача бизнеса в снижении нагрузки на службу поддержки (Вы написали), а безопасность, скорость выполнения операции и отсутствие ошибок гарантирует решение задач пользователя (Таня об этом сказала).
Все, что сказала Таня появилось как дополнительный результат в процессе решения основной задачи — увеличение прибыльности за счет снижения затрат. Для пользователя, который в случае любой своей ошибки, будет получать карту обратно и начинать все действия заново, это не улучшение юзабилити, а раздражающий фактор. Безопасность можно решать несколькими способами. Не секрет, что все банкоматы снабжены камерами. Отошел от банкомата без карточки — она «съедается». Ошибки пользователя можно сократить путем улучшения обратной связи через информирование о состоянии банкомата и производимых операциях. Кстати, хоть многие не любят Приват Банк, но их банкоматы пищат, если карточка внутри и пользователь долго не взаимодействует с интерфейсом. Простое решение проблем склеротиков. Итак, что мы видим? Банк решал свою задачу, а юзабилити-специалисты сделали из симптомов решения выводы, что это лучше для пользователя. Это и есть главная ошибка юзабилити-специалистов.
Вы не адекватны не тем, что пишите, а тем, что Вы спорите с видеозаписью лекции в которой нельзя вместить все возможные ситуации. В комментариях можно придумать любую ситуацию и перекрутить всё как угодно. В лекции важно передать подход, что Таня и сделала.
Подход неправильный. Я с этим и спорю. Взяты симптомы и на них развита целая теория. Удобно? Да, но не продуктивно. Аудитория не будет задумываться над истинными причинами, а будет долго обсасывать ложные выводы. Аудитории нужно давать пищу для размышления, а не готовые интерпретации. (Правда, если ваша цель как раз не заключается в том, чтобы намеренно сформировать мнение).
И заявления про адекватность оставьте себе. Лучше больше конструктива в разговоре, чем пустые замечания.
И заявления про адекватность оставьте себе. Лучше больше конструктива в разговоре, чем пустые замечания.
Если не ошибаюсь, то ни разу не прозвучали такие слова, как эргономика, инженерная психология… а это ключевые моменты в данном вопросе.
Возражаю. Это лекция по юзабилити для программистов, расширение кругозора.
По мне так 95% людей достаточно прочитать желтую книжку Круга.
По мне так 95% людей достаточно прочитать желтую книжку Круга.
А что есть юзабилити?
В моем сообщении = проектирование интерфейсов, используя придуманную гуру методологию и практики.
А обычно юзабилити для обычных людей = удобство использования, которая состоит из эргономики, особенностей человеческого восприятия, психофизики, эстетики и других составных частей. Эргономика интерфейса, как для меня, это самая важная часть юзабилити. Так что возражение было очень сильно уместным.
Не убедили.
Перефразирую мысль: «95% процентам людей участвующих в разработке ПО достаточно знать юзабилити на уровне желтой книжки Круга»
А то вы говорите это buzzwords, ни один нормальный проектировщик не думает об «особенностях человеческого воприятия и психофизике» когда пишет пользовательские сценарии или рисует вайерфреймы.
Есть теоретическая физика, а есть остальные 90% айсберга.
Перефразирую мысль: «95% процентам людей участвующих в разработке ПО достаточно знать юзабилити на уровне желтой книжки Круга»
А то вы говорите это buzzwords, ни один нормальный проектировщик не думает об «особенностях человеческого воприятия и психофизике» когда пишет пользовательские сценарии или рисует вайерфреймы.
Есть теоретическая физика, а есть остальные 90% айсберга.
Разработчикам не обязательно вообще знать что-то про юзабилити. Они должны совершествоваться в программировании, кодинге, но юзабилити оставить UI-проектировщикам. Разработчику должно быть пофиг, один файл пользователь аплоадит на сервер, или пачку, но это очень важно проектировщикам.
И не стоит додумывать за меня. Я не говорил тех фраз, что вы мне приписали.
Я акцентировал внимание на том, что наоборот, зачастую проектировщики думают о чем-то еще, кроме как о решении проблем пользователя. А для этого нужно начинать не с рисования картинок или написания сценариев поведения, а с изучения задач и проблем, которые возникают у пользователя в процессе работы в реальном мире.
Давайте приведу пример из реальной жизни. Я работал над интерфейсом системы автоматизации бизнес-процессов одной финансовой компании. Отдел кадров. Обычные задачи, которые стоят перед работниками этого отдела: прием и увольнение работников, заведение их персональных карточек, изменение должностей, распределение отпусков и другие. Как вы думаете, какой из интерфейсов для них самый важный? Никогда не догадаетесь — распределение отпусков. Все остальные задачи они делают раз в квартал. Подумайте теперь, какой бы вы нарисовали интерфейс, и какой хотели пользователи.
И не стоит додумывать за меня. Я не говорил тех фраз, что вы мне приписали.
Я акцентировал внимание на том, что наоборот, зачастую проектировщики думают о чем-то еще, кроме как о решении проблем пользователя. А для этого нужно начинать не с рисования картинок или написания сценариев поведения, а с изучения задач и проблем, которые возникают у пользователя в процессе работы в реальном мире.
Давайте приведу пример из реальной жизни. Я работал над интерфейсом системы автоматизации бизнес-процессов одной финансовой компании. Отдел кадров. Обычные задачи, которые стоят перед работниками этого отдела: прием и увольнение работников, заведение их персональных карточек, изменение должностей, распределение отпусков и другие. Как вы думаете, какой из интерфейсов для них самый важный? Никогда не догадаетесь — распределение отпусков. Все остальные задачи они делают раз в квартал. Подумайте теперь, какой бы вы нарисовали интерфейс, и какой хотели пользователи.
> И не стоит додумывать за меня. Я не говорил тех фраз, что вы мне приписали.
ORLY? Вы не писали слова «особенности человеческого восприятия, психофизика, экстетика»
В вашем примере с отделом кадров я бы просто поговорил с людьми при составлении пользовательских сценариев и бы уж точно не задумывался о вышеуказанных словах.
А основы проектирования интерфейсов, на мой взгляд, должны знать все. Прежде всего менеджеры, затем программисты и тестировщики.
ORLY? Вы не писали слова «особенности человеческого восприятия, психофизика, экстетика»
В вашем примере с отделом кадров я бы просто поговорил с людьми при составлении пользовательских сценариев и бы уж точно не задумывался о вышеуказанных словах.
А основы проектирования интерфейсов, на мой взгляд, должны знать все. Прежде всего менеджеры, затем программисты и тестировщики.
>>> А то вы говорите это buzzwords, ни один нормальный проектировщик не думает об «особенностях человеческого воприятия и психофизике» когда пишет пользовательские сценарии или рисует вайерфреймы.
Тогда уточните, что вы имели в виду вот этим предложением. Это ваше мнение, или это ваша интерпретация моих слов?
Тогда уточните, что вы имели в виду вот этим предложением. Это ваше мнение, или это ваша интерпретация моих слов?
Мои утверждения:
1. «особенности человеческого восприятия, психофизика, экстетика» = en.wikipedia.org/wiki/Buzzword
2. для создания хорошего интерфейса, задумываться о таких вещах не обязательно
1. «особенности человеческого восприятия, психофизика, экстетика» = en.wikipedia.org/wiki/Buzzword
2. для создания хорошего интерфейса, задумываться о таких вещах не обязательно
1. Базворды? Да вы что, серьезно? Это норма в фотографии, дизайне, и никакие не модные словечки. Вы не сможете создать ни один дизайн без применения этих терминов, даже самый убогий. Потому что «убогость» будет результатом оценки объектов вашим мозгом, пропущенное через особенности вашего восприятия, через вашу ментальную модель поведения, через ваши эстетические нормы.
2. Вы будете подневольно применять описанное выше при создании любого интерфейса. Нужно развивать эти качества, чтобы получить действительно хороший интерфейс.
Обратимся к примеру. Есть красный цвет. Он может символизировать как об опасности, так и наоборот, о том, что это безопасно. Красный металл говорит про то, что скорее всего он раскален и трогать нельзя. Красное яблоко говорит вам, что это спелый плод и он готов к употреблению. Но оба варианта будут невольно привлекать ваше внимание. Оценка данного факта сильно зависит от ситуации. Допустим, если интерфейс перегружен красными элементами, то будет трудно заставить человека увидеть еще больший акцент. Вместо цвета придется кодировать важность другими способами: размеры элементов, десатурация окружающих элементов, анимация, и так далее. А вы говорите, что особенности восприятия не важны…
2. Вы будете подневольно применять описанное выше при создании любого интерфейса. Нужно развивать эти качества, чтобы получить действительно хороший интерфейс.
Обратимся к примеру. Есть красный цвет. Он может символизировать как об опасности, так и наоборот, о том, что это безопасно. Красный металл говорит про то, что скорее всего он раскален и трогать нельзя. Красное яблоко говорит вам, что это спелый плод и он готов к употреблению. Но оба варианта будут невольно привлекать ваше внимание. Оценка данного факта сильно зависит от ситуации. Допустим, если интерфейс перегружен красными элементами, то будет трудно заставить человека увидеть еще больший акцент. Вместо цвета придется кодировать важность другими способами: размеры элементов, десатурация окружающих элементов, анимация, и так далее. А вы говорите, что особенности восприятия не важны…
Александр, я заканчиваю эту интереснейшую дискуссию, мне вас не переубедить, да и работать нужно :)
Если вы всерьез считаете, что нельзя создать хороший интерфейс без мыслей о «психофизике», это ваше право и мне тут нечего добавить.
Если вы всерьез считаете, что нельзя создать хороший интерфейс без мыслей о «психофизике», это ваше право и мне тут нечего добавить.
Не нужно думать о психофизике как о субъекте! Вы должны ставить себя на место пользователя, смотреть на мир его примитивными и приземленными взглядами. Вы должны понимать его переживания по поводу его взаимодействия с интерфейсом, понимать реакцию на раздражители, строить раздражители таким образом, чтобы они вызывали нужную реакцию. Вы сделали мигающий фон страницы? Подумайте, какой шок будет у пользователя от этого.
Я тут позаимствовал Вашу золотые слова habrahabr.ru/company/e-Legion/blog/118559/#comment_3877108 если Вы не против :)
Александр уж больно зануден.
Александр уж больно зануден.
нет, конечно :) Я сам так раньше спорил со всеми, но потом понял, что в этом нет смысла. Лишняя трата джоулей.
Мда, конструктивной беседы не получилось. Но ярлыков на меня уже с мешок навешали… Обожаю Хабр!
Если вы работаете в этой отрасли, то должны уметь слушать и слышать. В своих сообщениях вы транслируете однобокое понимание отрасли. Иногда пишите интересные и местами правильные вещи, но подача утомляет. Советы и аргументы вы не слушаете, поэтому лично мне с вами не хочется ничего обсуждать. Простите.
Покажите мне пример разнобокого понимания отрасли.
Цепляться к подаче может только тот человек, которому нечего сказать по сути. Очень легко становиться в позу и говорить «да что вы понимаете!».
Советы и аргументы были? Простите, не увидел. Можете ткнуть пальцем? Я в своих постах привел массу примеров, хоть один написал, что они неправильные? Где правильные примеры в ответ?
Ах да, я зануден и неадекватен, что с меня взять… :)
Цепляться к подаче может только тот человек, которому нечего сказать по сути. Очень легко становиться в позу и говорить «да что вы понимаете!».
Советы и аргументы были? Простите, не увидел. Можете ткнуть пальцем? Я в своих постах привел массу примеров, хоть один написал, что они неправильные? Где правильные примеры в ответ?
Ах да, я зануден и неадекватен, что с меня взять… :)
И да, если вы себя ставите в один ряд с «теоретическими физиками» типа Нильсена и Раскина, подкиньте мне ссылочки на свои публикации в области юзабилити.
Сперва добейся…
Чтобы быть юзабилити-специалистом, не обязательно публиковать свои статьи. Чтобы оценивать вкус еды, не нужно быть шеф-поваром в элитном ресторане, чтобы дать оценку фильму, не нужно быть Камероном. Надеюсь, аналогия понятна?
Чтобы быть юзабилити-специалистом, не обязательно публиковать свои статьи. Чтобы оценивать вкус еды, не нужно быть шеф-поваром в элитном ресторане, чтобы дать оценку фильму, не нужно быть Камероном. Надеюсь, аналогия понятна?
Чтобы лечить и делать операции не надо быть доктором, чтобы водить машину не надо иметь права. Если выше у вас всё ровно написано, то в этом месте Ваши рассуждения достаточно примитивны. Чтобы быть юзабилити-специалистом действительно не нужно публиковать статьи, но специалистом всё же быть нужно. Кроме того юзабилити-специалистами в отрасли называют не проектировщиков интерфейсов, а людей работающих по другим активностям.
НЛО прилетело и опубликовало эту надпись здесь
Обычно, чтобы понять уровень собеседника, люди заводят конструктивную беседу. Хотите возразить вышесказанному? Возражайте! Аргументируйте! Но не задавайте вопрос «А чего добился ты?». Иначе спор может быстро скатиться до уровня: «И это мне говорит человек, который не написал ни одной статьи по юзабилити». Предвзятое отношение к оппоненту никогда еще не приводило к полезной для окружающих беседе.
М. Горький цитирует А. Чехова:
— Критики похожи на слепней, которые мешают лошади пахать землю, — говорил он [Чехов], усмехаясь умной своей усмешкой. – Лошадь работает, все мускулы натянуты, как струны на контрабасе, а тут на крупе садится слепень и щекочет и жужжит. Нужно встряхивать кожей и махать хвостом. О чем он жужжит? Едва ли ему понятно это. Просто характер у него беспокойный и заявить о себе хочется, — мол, тоже на земле живу! Вот видите, — могу даже жужжать, обо всем могу жужжать! Я двадцать пять лет читаю критики на мои рассказы, а ни одного ценного указания не помню, ни одного доброго совета не слышал. Только однажды Скабичевский произвел на меня впечатление, он написал, что я умру в пьяном виде под забором…
К чему я веду? Я веду к тому, что вы ничего не предлагаете взамен, не указываете конкретные недостатки, таким образом показывая свою осведомленность или свою точку зрению, которую можно обсудить, а просто закидываете «умными» словами, показывая свою невежественность в вопросе. Помните, как в фильме было?
— Извините, милостивый государь, вы меня не так поняли.
— Да как же тебя понять, коль ты ничего не говоришь?
— Критики похожи на слепней, которые мешают лошади пахать землю, — говорил он [Чехов], усмехаясь умной своей усмешкой. – Лошадь работает, все мускулы натянуты, как струны на контрабасе, а тут на крупе садится слепень и щекочет и жужжит. Нужно встряхивать кожей и махать хвостом. О чем он жужжит? Едва ли ему понятно это. Просто характер у него беспокойный и заявить о себе хочется, — мол, тоже на земле живу! Вот видите, — могу даже жужжать, обо всем могу жужжать! Я двадцать пять лет читаю критики на мои рассказы, а ни одного ценного указания не помню, ни одного доброго совета не слышал. Только однажды Скабичевский произвел на меня впечатление, он написал, что я умру в пьяном виде под забором…
К чему я веду? Я веду к тому, что вы ничего не предлагаете взамен, не указываете конкретные недостатки, таким образом показывая свою осведомленность или свою точку зрению, которую можно обсудить, а просто закидываете «умными» словами, показывая свою невежественность в вопросе. Помните, как в фильме было?
— Извините, милостивый государь, вы меня не так поняли.
— Да как же тебя понять, коль ты ничего не говоришь?
Какая из тем, затронутых мной, вас интересует? Хотите поговорить про привычки в интерфейсах? Или про нарушенную причинно-следственную связь? Или про поведенческие модели пользователей? Или про эргономику цветов? Я готов говорить конструктивно, если собеседнику что-то не понятно и он хочет получить пищу для размышления. Но если все не понятно, то я выступать в роли китайского радио не сильно заинтересован.
Для программистов, которые пишут программы аля «Чужие для хищников»?
Очень можно стало об интерфейсах нынче говорить. Говорить, не делать — 97% интерфейсов до сих пор говно, ничего не меняется. Но говорить стало модно. Бирмановщина называется. Аж потряхивает от этих «Адоби».
Среди этапов разработки интерфейса не обнаружил этапа «Прототипирование», хотя, на мой взгляд, живой, кликабельный прототип в разы более наглядный и понятный, нежели набор скриншотов экранов, взаимосвязь между которыми описана в текстовом виде. К тому же, по прототипу заказчик имеет возможность целостно оценить удобство и юзабельность будущей системы. Значительно снижается вероятность возникновения ситуаций «я думал, что будет так, а вы сделали по-другому». Прототипирование особенно актуально, наверное, для сложных систем со множеством экранов, когда хранить в голове взаимосвязь этих экранов становится просто невозможно, но вроде как необходимо для формирования целостной картины о приложении.
Ограничений не вижу: есть инструменты на любой вкус, многие компании уже осознали необходимость в прототипировании и активно и весьма успешно его используют.
Ограничений не вижу: есть инструменты на любой вкус, многие компании уже осознали необходимость в прототипировании и активно и весьма успешно его используют.
отчасти вы правы, прототипы это здорово.
С другой стороны, их долго и дорого делать, я быстрее сверстаю и закодирую страничку, чем создам прототип.
Поэтому мы пропускаем этап прототипирования, останавливаемся на wireframes + комментарии к ним. И даже проводим тестирование на wireframes.
С другой стороны, их долго и дорого делать, я быстрее сверстаю и закодирую страничку, чем создам прототип.
Поэтому мы пропускаем этап прототипирования, останавливаемся на wireframes + комментарии к ним. И даже проводим тестирование на wireframes.
Если речь идёт о сложном веб или десктоп-приложении, а не о простеньком веб-сайте, где большая часть работы — создание дизайна или вёрстка, а не кодирование, то в этом случае едва ли возможно закодировать экран быстрее, чем создать прототип.
Во-вторых, во многих компаниях с заказчиками общаются не разработчики, а аналитики и менеджеры проектов, которые кодить не умеют. Чтобы визуализировать требования от заказчика, они как раз могут создавать прототипы достаточно просто, без кодирования.
В-третьих, прогеры не любят выбрасывать написанный код. Если заказчику не понравилось то, что вы накодировали — едва ли вы выбросите написанный код и начнёте работу с нуля. Большинство будет изменять то, что уже накодировано, перетаскивая прошлые ошибки и недочёты. В конце концов есть риск получить на выходе плохой код. При наличии прототипа изменения будут вноситься именно в прототип, что намного безболезненнее. Реализовываться уже будет окончательная версия прототипа, утверждённая и задокументированная.
Во-вторых, во многих компаниях с заказчиками общаются не разработчики, а аналитики и менеджеры проектов, которые кодить не умеют. Чтобы визуализировать требования от заказчика, они как раз могут создавать прототипы достаточно просто, без кодирования.
В-третьих, прогеры не любят выбрасывать написанный код. Если заказчику не понравилось то, что вы накодировали — едва ли вы выбросите написанный код и начнёте работу с нуля. Большинство будет изменять то, что уже накодировано, перетаскивая прошлые ошибки и недочёты. В конце концов есть риск получить на выходе плохой код. При наличии прототипа изменения будут вноситься именно в прототип, что намного безболезненнее. Реализовываться уже будет окончательная версия прототипа, утверждённая и задокументированная.
по первому абзацу согласен.
по второму, аналитики/менеджеры, мне кажется, должны описывать пользовательские сценарии, а прототипы делать уже проектировщики
про плохой код не согласен
по второму, аналитики/менеджеры, мне кажется, должны описывать пользовательские сценарии, а прототипы делать уже проектировщики
про плохой код не согласен
Готов спорить, любой экран прототипа www.youtube.com/watch?v=PhVNBUEN7bc вы будете кодить дольше, чем я прототипировать.
Должности в разных компаниях приобретают разные оттенки, неважно как вы его назовёте: проектировщик, аналитик, менеджер. Если вы заметили, я делал акцент на характеристики:
1. Общается с заказчиком
2. Программировать не умеет
Именно человек, который общается с заказчиком, на мой взгляд, должен заниматься разработкой прототипа для минимизации потерь информации по пути от заказчика к разработчику.
Доводы?
Должности в разных компаниях приобретают разные оттенки, неважно как вы его назовёте: проектировщик, аналитик, менеджер. Если вы заметили, я делал акцент на характеристики:
1. Общается с заказчиком
2. Программировать не умеет
Именно человек, который общается с заказчиком, на мой взгляд, должен заниматься разработкой прототипа для минимизации потерь информации по пути от заказчика к разработчику.
Доводы?
Ой, а мы уже спорили по этому вопросу лично в Ингрии :)
Я готов с вами посоревноваться в скорости, где, когда, на что спорим? Я камеру принесу, сделаем потом пост по результатам.
По-моему, прототип должен делать проектировщик, а не аккаунт. Аккаунт должен заканчивать на пункте 4 стуктуризации (http://www.uxdepot.ru/process). Но в каждой организации все по разному и у меня нет в это большого опыта.
Про прототипы я с вами согласен, спорил по инерции, хороших софт для интерактивных wireframes это здорово.
Я готов с вами посоревноваться в скорости, где, когда, на что спорим? Я камеру принесу, сделаем потом пост по результатам.
По-моему, прототип должен делать проектировщик, а не аккаунт. Аккаунт должен заканчивать на пункте 4 стуктуризации (http://www.uxdepot.ru/process). Но в каждой организации все по разному и у меня нет в это большого опыта.
Про прототипы я с вами согласен, спорил по инерции, хороших софт для интерактивных wireframes это здорово.
Только так и делаем. Сперва практический полнофункциональный прототип, потом рефакторинг, потом реализация «внутренностей». Сокращает время разработки и количество ошибок в разы.
Речь хоть и живая, может волнение и сьемка сказывается, но выглядит как то не очень подгодтовленно когда вещи называют «я не знаю как эта штука называется» и т.д. Идеи которые она высказывала с одной стороны очевидны и понятны для хоть для немного поднаторенного человека, но не было четких формулировок. Те гуру которых она приводила и есть гуру, т.к. в своих книгах дают четкие и лаконичные формулировки процессов.
Пример с погодой ужасен, заслуженно наверняка есть про него много обсуждений и критики. Например куда наглядней и проще, а главное не противоречит духу иконок — показывать погоду в самой иконке, обновляя на лету. Человеку нет нужды даже программу погоды открывать. А облака, вид из космоса — в топку.
Пример с погодой ужасен, заслуженно наверняка есть про него много обсуждений и критики. Например куда наглядней и проще, а главное не противоречит духу иконок — показывать погоду в самой иконке, обновляя на лету. Человеку нет нужды даже программу погоды открывать. А облака, вид из космоса — в топку.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Таня Мисютина об интерфейсе