Интервью Ларри Теслера из книги Designing for Interaction.
Ларри Теслер — ветеран индустрии разработки GUI.
Работал в Xerox PARC, Apple Computer, Amazon.com, and Yahoo!
Изобретатель операции Cut&Paste, контекстного меню.
Только одно. Делайте дизайн именно для пользователей.
Во времена зарождения GUI, когда я работал в Xerox PARC, идея однородности пользовательского интерфейса была новой и спорной. Многие из нас понимали, что однородность пойдет на пользу не только пользователей, но и разработчиков, так как типовые элементы могут быть вынесены в разделяемые библиотеки. Мы выдвинули экономический аргумент: если мы в разработке основываемся на типовых элементах и поощряем однородность, то мы можем сократить время выхода на рынок и размер кода.
В 1983-85, когда я работал в MacApp и занимался объектно-ориентированным фреймворком для Apple, я выступал за трехслойную модель кода. В дополнение к Macintosh Toolbox (разделяемая библиотека) и самому фреймворку, я сделал промежуточный слой, который являлся, как я это назвал, «базовым приложением». Базовое приложение было настоящей интерактивной программой — с окнами, меню и командами, но не имело собственной функциональности, а лишь предоставляла стандартный путь для выполнения типовых действий. Скажем, вы могли в нём создавать, открывать, сохранять и печатать документы, но документы не имели содержания. Вы могли создать собственное приложение изменяя «базовое», как это принято при объектно ориентированном подходе.
Чтобы продать идею компании Apple и другим разработчикам, я придумал «Закон сохранения сложности». Я предположил, что каждое приложение имеет неуменьшаемый коэффициент сложности. Вопрос только в том, кого это касается в большей степени (т.е. программу легко разработать но сложно использовать, либо наоборот — прим. переводчика).
Так как компьютеры тогда были маленькие, медленные и дорогие, а программы были разработаны чтобы быть компактным, ПО было не простым в использовании. Со сложностью ПО приходилось бороться пользователю а не программисту. Но коммерческое ПО пишется всего один раз а используются миллионами. Если миллионы пользователей теряют минуту в день на борьбу с проблемой которую инженер мог бы устранили за неделю, просто сделав программное обеспечение немного более сложным в разработке но простым в использовании, вы наказание пользователя за то что ваш инженер бездельничает.
Чье время является более важным для успеха Вашего бизнеса? Для массового рынка программного обеспечения, если у вас нет устойчивой позиции монополии, время клиента должен быть для вас важнее, чем свои собственные.
Идея объектно-ориентированного программирования, разработанная Trygve Reenskaug в PARC, а также идея «базового приложения», которые я разработал с моей командой MacApp, сделали инвестиции в удобство ПО более приемлемой для разработчиков, т.к. позволили упростить их работу. Чем более сложности заключено на низком уровне иерархии ПО (в разработке) тем меньше её останется на верхнем уровне (т.е. у конечных пользователей — прим. переводчика). У MacApp был лозунг: «Если вы сделаете проще жизнь наших общих пользователей, мы сделаем для вас проще разработку».
Ошибки, которые делают начинающие дизайнеры, варьируют в значительной степени, частично они связаны с их обучением. Некоторые педагоги, особенно в факультеты информатики, рассказывают своим студентам, что нужно проектировать «как для себя». Если понимать буквально, то подобный совет ведет к GUI, который удобен только студентам компьютерных факультетов.
Я считаю, что только если вы научитесь ставить себя на место пользователя, то вы сможете проектировать «для себя» а на самом деле будете проектировать для пользователя. Я называю этот подход «метод дизайнера», потому что по смыслу он похож на «метод вживания» Станиславского («Method Design»/«Method acting» — прим. переводчика). В действительности, вы проектируете не для себя. Вы проектируете для «вашего персонажа». Конечно, для успеха этого метода, вы должны знать свой персонаж. Это одна из причин по которым дизайнеры должны учитывать этнографические исследования и usability.
Новички часто поддаются давлению со стороны руководства, направленному на экономию, и пропускают юзабилити-тесты, несмотря на серьезные нерешенные вопросы. С другой стороны, новички иногда запускать намного больше тестов, чем это необходимо, стараются охватить слишком много направлений, тратят слишком много времени на подготовку официальных докладов, или не в состоянии отстоять свою точку зрения. Юзабилити-тестирование всегда должно быть завершено ещё до того как дизайнер утверждает все спорные элементы интерфейса. Но тестирование должно проводиться в самым дешевым из возможных способов.
Конечно, иногда бывает необходимо, чтобы продемонстрировать ценность исследований для скептиков. В этом случае, стоит взять пару часов для подготовку видеоролика, подчеркивающего всю серьезность путаницы пользователей.
Две другие ошибки которые начинающие дизайнеры допускают чаще опытных, это игнорирование стандартов или, напротив, слепое следование стандартам. Стандарты, как правило, благо, поэтому нужно очень веские основания для отхода от стандартов. Пока вы не убедитесь что пользователям действительно удобней работать с нестандартными элементами GUI, вы не можете быть уверенными в обоснованности их применения.
Выбор слов имеет большое значение. Более короткие, как правило, лучше. Но если вы вынуждены объяснять многим пользователям что означает «х» (или еще хуже, вашим товарищам по команде), то вам вероятно, следует заменить слово «х» на те, которыми вы это описывали в объяснениях.
На мой взгляд, основное, что отделяет эксперта от начинающего дизайнера, это возможность выбрать подходящее решение из большего количества возможных. Глядя на одну и ту же проблему, новичок и эксперт, могут в первую очередь думаем об одинаковом решении, скажем, о многостраничные GUI с многочисленными формами. Но новичок, вероятно, будет зацикливаться на решении, даже если он чрезмерно сложное. Опытный дизайнер рассмотрит радикальные альтернативы, скажем, возможность пользователю увидеть данные так, как это будет выглядеть в конечном состоянии и редактировать его на месте.
Опытный дизайнер не остановится, пока не сделает дизайн достаточно простым для пользователя. Не обязательно эта работа займёт несколько месяцев. Это может занять несколько дней или часов, даже секунд. Отличный дизайн часто занимает много времени, но это расточительным является не это, а затраты на дизайн который окажется недостаточно прост чтобы войти в окончательный продукт.
Ларри Теслер — ветеран индустрии разработки GUI.
Работал в Xerox PARC, Apple Computer, Amazon.com, and Yahoo!
Изобретатель операции Cut&Paste, контекстного меню.
Какие существуют основные правила для дизайнеров интерфейсов?Только одно. Делайте дизайн именно для пользователей.
Как вам пришёл в голову закон Теслера о сохранении сложности?Во времена зарождения GUI, когда я работал в Xerox PARC, идея однородности пользовательского интерфейса была новой и спорной. Многие из нас понимали, что однородность пойдет на пользу не только пользователей, но и разработчиков, так как типовые элементы могут быть вынесены в разделяемые библиотеки. Мы выдвинули экономический аргумент: если мы в разработке основываемся на типовых элементах и поощряем однородность, то мы можем сократить время выхода на рынок и размер кода.
В 1983-85, когда я работал в MacApp и занимался объектно-ориентированным фреймворком для Apple, я выступал за трехслойную модель кода. В дополнение к Macintosh Toolbox (разделяемая библиотека) и самому фреймворку, я сделал промежуточный слой, который являлся, как я это назвал, «базовым приложением». Базовое приложение было настоящей интерактивной программой — с окнами, меню и командами, но не имело собственной функциональности, а лишь предоставляла стандартный путь для выполнения типовых действий. Скажем, вы могли в нём создавать, открывать, сохранять и печатать документы, но документы не имели содержания. Вы могли создать собственное приложение изменяя «базовое», как это принято при объектно ориентированном подходе.
Чтобы продать идею компании Apple и другим разработчикам, я придумал «Закон сохранения сложности». Я предположил, что каждое приложение имеет неуменьшаемый коэффициент сложности. Вопрос только в том, кого это касается в большей степени (т.е. программу легко разработать но сложно использовать, либо наоборот — прим. переводчика).
Так как компьютеры тогда были маленькие, медленные и дорогие, а программы были разработаны чтобы быть компактным, ПО было не простым в использовании. Со сложностью ПО приходилось бороться пользователю а не программисту. Но коммерческое ПО пишется всего один раз а используются миллионами. Если миллионы пользователей теряют минуту в день на борьбу с проблемой которую инженер мог бы устранили за неделю, просто сделав программное обеспечение немного более сложным в разработке но простым в использовании, вы наказание пользователя за то что ваш инженер бездельничает.
Чье время является более важным для успеха Вашего бизнеса? Для массового рынка программного обеспечения, если у вас нет устойчивой позиции монополии, время клиента должен быть для вас важнее, чем свои собственные.
Идея объектно-ориентированного программирования, разработанная Trygve Reenskaug в PARC, а также идея «базового приложения», которые я разработал с моей командой MacApp, сделали инвестиции в удобство ПО более приемлемой для разработчиков, т.к. позволили упростить их работу. Чем более сложности заключено на низком уровне иерархии ПО (в разработке) тем меньше её останется на верхнем уровне (т.е. у конечных пользователей — прим. переводчика). У MacApp был лозунг: «Если вы сделаете проще жизнь наших общих пользователей, мы сделаем для вас проще разработку».
Каковы наиболее распространенные ошибки, которые делают начинающие дизайнеры GUI?Ошибки, которые делают начинающие дизайнеры, варьируют в значительной степени, частично они связаны с их обучением. Некоторые педагоги, особенно в факультеты информатики, рассказывают своим студентам, что нужно проектировать «как для себя». Если понимать буквально, то подобный совет ведет к GUI, который удобен только студентам компьютерных факультетов.
Я считаю, что только если вы научитесь ставить себя на место пользователя, то вы сможете проектировать «для себя» а на самом деле будете проектировать для пользователя. Я называю этот подход «метод дизайнера», потому что по смыслу он похож на «метод вживания» Станиславского («Method Design»/«Method acting» — прим. переводчика). В действительности, вы проектируете не для себя. Вы проектируете для «вашего персонажа». Конечно, для успеха этого метода, вы должны знать свой персонаж. Это одна из причин по которым дизайнеры должны учитывать этнографические исследования и usability.
Новички часто поддаются давлению со стороны руководства, направленному на экономию, и пропускают юзабилити-тесты, несмотря на серьезные нерешенные вопросы. С другой стороны, новички иногда запускать намного больше тестов, чем это необходимо, стараются охватить слишком много направлений, тратят слишком много времени на подготовку официальных докладов, или не в состоянии отстоять свою точку зрения. Юзабилити-тестирование всегда должно быть завершено ещё до того как дизайнер утверждает все спорные элементы интерфейса. Но тестирование должно проводиться в самым дешевым из возможных способов.
Конечно, иногда бывает необходимо, чтобы продемонстрировать ценность исследований для скептиков. В этом случае, стоит взять пару часов для подготовку видеоролика, подчеркивающего всю серьезность путаницы пользователей.
Две другие ошибки которые начинающие дизайнеры допускают чаще опытных, это игнорирование стандартов или, напротив, слепое следование стандартам. Стандарты, как правило, благо, поэтому нужно очень веские основания для отхода от стандартов. Пока вы не убедитесь что пользователям действительно удобней работать с нестандартными элементами GUI, вы не можете быть уверенными в обоснованности их применения.
Выбор слов имеет большое значение. Более короткие, как правило, лучше. Но если вы вынуждены объяснять многим пользователям что означает «х» (или еще хуже, вашим товарищам по команде), то вам вероятно, следует заменить слово «х» на те, которыми вы это описывали в объяснениях.
На мой взгляд, основное, что отделяет эксперта от начинающего дизайнера, это возможность выбрать подходящее решение из большего количества возможных. Глядя на одну и ту же проблему, новичок и эксперт, могут в первую очередь думаем об одинаковом решении, скажем, о многостраничные GUI с многочисленными формами. Но новичок, вероятно, будет зацикливаться на решении, даже если он чрезмерно сложное. Опытный дизайнер рассмотрит радикальные альтернативы, скажем, возможность пользователю увидеть данные так, как это будет выглядеть в конечном состоянии и редактировать его на месте.
Опытный дизайнер не остановится, пока не сделает дизайн достаточно простым для пользователя. Не обязательно эта работа займёт несколько месяцев. Это может занять несколько дней или часов, даже секунд. Отличный дизайн часто занимает много времени, но это расточительным является не это, а затраты на дизайн который окажется недостаточно прост чтобы войти в окончательный продукт.
