Ваш return_new_copy
изменяет передаваемый параметр, что, вероятно, нежелательно. Это также переопределяет в неправильном направлении (отдавая приоритет self.attributes
)
Я бы написал это следующим образом:
def return_new_copy(self, additional_attributes):
# python<3.5 if there are only string keys:
# attributes = dict(self.attributes, **additional_attributes)
# python<3.5 if there are non-string keys:
# attributes = self.attributes.copy()
# attributes.update(additional_attributes)
# python3.5+
attributes = {**self.attributes, **additional_attributes}
return type(self)(attributes)
Несколько тонкостей: - Я обязательно скопировать оба входные атрибуты и атрибуты self - я объединяю дополнительные атрибуты поверх атрибутов self
Если вы ищете что-то, чтобы сделать это автоматически, вы можете проверить namedtuple
[115 ]
Например:
>>> C = collections.namedtuple('C', ('a', 'b'))
>>> x = C(1, 2)
>>> x
C(a=1, b=2)
>>> y = x._replace(b=3)
>>> y
C(a=1, b=3)
>>> x
C(a=1, b=2)
Позвольте мне сказать это непосредственно:
Изменение к лучшему этого не начинается с инструкций. Это начинается с переструктурирования, как Вы думаете о программном обеспечении.
Большинство жестких разработчиков имеет практически нулевое сочувствие к пользователям их программного обеспечения. Они имеют никакая подсказка , как пользователи думают, как пользователи создают модели программного обеспечения, которое они используют и как они используют компьютер в целом.
Это - типичная проблема, когда эксперт сталкивается с неспециалисты: Как же нормальный человек мог быть так немой для не понимания то, что эксперт понял 10 лет назад?
Один из первых фактов, которые подтвердят, который это невероятно трудно схватить почти для всех опытных разработчиков, является этим:
у Нормальных людей есть весьма другое понятие программного обеспечения, чем Вы имеете. У них нет подсказки вообще программирования.Ничего. Нуль. И они даже не заботятся. Они даже не думают, что должны заботиться. Если Вы вынудите их к, то они удалят Вашу программу.
Теперь это невероятно резко для разработчика. Он гордится программным обеспечением, которое он производит. Он любит каждую функцию. Он может сказать Вам точно, как код позади него работает. Возможно, он даже изобрел невероятный умный алгоритм, который заставил его работать на 50% быстрее, чем прежде.
И пользователь не заботится.
, Что идиот.
Многие разработчики не могут выдержать работать с обычными пользователями. Они подавлены их неимеющимися знаниями технологии. И вот почему большинство разработчиков уклоняется и думает, что пользователи должны быть идиотами.
Они не.
, Если разработчик программного обеспечения покупает автомобиль, он ожидает, что это будет работать гладко. Он обычно не заботится о давлении в шине, механическое устройство, подстраивающее, который был важен, чтобы заставить его выполнить тот путь. Здесь он не эксперт. И если он покупает автомобиль, который не имеет подстройки, он отдает ее и покупает ту, которая делает то, что он хочет.
Многие разработчики программного обеспечения как фильмы. Хорошо сделанные фильмы, которые зажигают их воображение. Но они не эксперты в создании фильмов в произведении визуальных эффектов или в записи хороших сценариев фильма. Большинство компьютерных фанатов очень, очень, очень плохо при действии, потому что это - все об отображении сложных эмоций и мало об аналитике. Если разработчик смотрит плохой фильм, он просто замечает, что это плохо в целом. Компьютерные фанаты даже создали IMDb для сбора информации о хороших и плохих фильмах, таким образом, они знают, которые смотреть и чтобы избежать. Но они не эксперты в создании фильмов. Если фильм будет плох, то они не пойдут в кино (или не загрузят его с БитТоррента ;)
, Таким образом, он сведется к: Избегание обычных пользователей как эксперт незнание. , поскольку в тех областях (и существуют так многие), где они не эксперты, они ожидают, что эксперты других областей будут уже думать о нормальных людях, которые используют их продукты или услуги.
, Что можно сделать для исправления его? Чем более жесткие Вы как программист, тем менее открыты Вы будете для обычного пользователя, думающего. Это будет посторонним и невежественным Вам. Вы будете думать: Я не могу вообразить, как люди могли когда-либо , используют компьютер с этим отсутствием знаний. Но они могут. Для каждого элемента UI думайте о: действительно ли это необходимо? Это соответствует к понятию, которое пользователь имеет моего инструмента? Как я могу заставить его понять? Читайте на удобстве использования для этого, существует много хороших книг. Это - целая область науки, также.
А-ч и перед высказыванием этого, да, я - поклонник Apple ;)
Что действительно помогает мне улучшиться, мой дизайн должен захватить такого же разработчика, один парни QA, премьер-министр или любой, кто, оказывается, идет и сделал, чтобы они испытали конкретный виджет или экран.
Его удивительное, что Вы поймете, когда Вы будете наблюдать, что кто-то еще использует Ваше программное обеспечение впервые
В конечном счете это действительно о сочувствии - можно ли поместить себя в обувь Вашего пользователя?
Одна вещь, которая помогает, конечно, "ест Ваш собственный собачий корм" - использование Ваших приложений как реальный пользователь самостоятельно и наблюдение, что является раздражающим.
Другая хорошая идея состоит в том, чтобы найти способ наблюдать за реальным пользователем, использующим Ваше приложение, которое может быть столь же сложным как лаборатория удобства использования с односторонними зеркалами, экранной видеосъемкой, видеокамерами на пользователях, и т.д., или может быть столь же простым как бумажная разработка прототипа с помощью следующего человека, который, оказывается, спускается с Холла.
, Если все остальное перестало работать, помните, что для UI почти всегда лучше быть слишком простым, чем слишком сложный. Очень очень легко сказать, "о, я знаю, как решить это, я просто добавлю флажок, таким образом, пользователь сможет решить, какой режим они предпочитают". Скоро Ваш UI является слишком сложным. Выберите режим по умолчанию и установите предпочтительную настройку усовершенствованный параметр конфигурации. Или просто пропустите его.
, Если Вы читаете много о дизайне, можно легко стать одержимыми отброшенными тенями и скругленными углами и т.д. Это не важный материал. Простота и discoverability являются важным материалом.
Вопреки популярному мифу в дизайне UI нет буквально никаких мягких аспектов, по крайней мере не больше, чем должен был разработать хороший бэкэнд.
Рассматривают следующее; хороший дизайн бэкэнда основан на довольно твердых принципах и элементах, с которыми любой хороший разработчик знаком:
слабая связь
высокая связность
архитектурные шаблоны
промышленные лучшие практики
и т.д.
Хороший дизайн бэкэнда обычно рождается через многие взаимодействия, где на основе измеримой обратной связи, полученной во время тестов или фактического использования, начальный проект постепенно улучшается. Иногда необходимо моделировать меньшие аспекты бэкэнда и испытать их в изоляции и т.д.
, Хороший дизайн UI основан на звуковых принципах:
видимость
подразумеваемая возможность
обратная связь
допуск
простота
непротиворечивость
структура
UI также рождается через тест и пробную версию, посредством повторений, но не с компилятором + автоматизированный тестовый иск, но люди. Так же к бэкэнду существуют промышленные методы наиболее успешной практики, измерение и методы оценки, способы думать о UI и установить цели с точки зрения пользовательской модели, образа системы, модели разработчика, структурной модели, функциональная модель и т.д.
, набор навыков, необходимый для разработки UI, очень отличается от разработки бэкенда, и следовательно don’t ожидают мочь сделать хороший UI, не делая некоторого изучения сначала. Однако то, что обе этих операции имеют общего, является процессом дизайна. Я полагаю, что любой, кто может разработать хорошее программное обеспечение, способен к разработке хорошего UI, пока они проводят некоторое время, учась как.
я рекомендую брать курс в Человеко-машинном взаимодействии, проверяю MIT и Йельский сайт, например, для материалов онлайн:
Структурный по сравнению с Функциональной моделью в Понимании и Использовании
превосходное ранее сообщение Thorsten79 поднимает тему экспертов по разработке программного обеспечения по сравнению с пользователями и как их понимание программного обеспечения отличается. Эксперты по изучению - люди различают функциональные и структурные умственные модели. Нахождение пути к дому Вашего друга может быть превосходным примером различия между двумя:
Первый подход включает ряд подробных инструкций: возьмите первый выход автострады, затем после того, как 100 ярдов повернут налево и т.д. Это - пример функциональной модели: список конкретных шагов, необходимых для достижения определенной цели. Функциональные модели просты в использовании, они не требуют больших взглядов просто прямое выполнение. Очевидно, существует штраф за простоту: это не мог бы быть наиболее эффективный маршрут, и любая любая исключительная ситуация (т.е. транспортная диверсия) может легко привести к полному отказу.
А другой способ справиться с задачей состоит в том, чтобы создать структурную умственную модель. В нашем примере, который был бы картой, которая передает большую информацию о внутренней структуре "объекта задачи". От понимания карты и относительных местоположений дома нашего и друга мы можем вычесть функциональную модель (маршрут). Очевидно, это, требует большего усилия, но намного более надежного способа выполнить задачу несмотря на возможные отклонения.
выбор между передачей функциональной или структурной модели через UI (например, мастер по сравнению с расширенным режимом) не состоит в том, что прямой, поскольку это могло бы казаться из сообщения Thorsten79. Усовершенствованные и частые пользователи могли бы хорошо предпочесть структурную модель, тогда как случайные или менее опытные пользователи — функциональный.
Google отображается, яркий пример: они включают и функциональную и структурную модель, сделайте многие сидели navs.
Другой размер проблемы - то, что структурная модель, представленная через UI, не должна отображаться на структуру программного обеспечения, а скорее естественно отображаться на структуру пользовательской задачи под рукой или включенного объекта задачи.
трудность здесь состоит в том, что у многих разработчиков будет хорошая структурная модель их внутренностей программного обеспечения, но только функциональная модель пользователя определяет задачу для целей программного обеспечения помочь в. Для создания хорошего UI, нужно понять структуру задачи/объекта задачи и отобразить UI на ту структуру.
Так или иначе, я все еще не могу рекомендовать брать формальный курс HCI достаточно сильно. Существует много материала, включенного такой как эвристика , принципы, полученные от гештальт phychology , способы, которыми люди учатся и т.д.
Я предлагаю, чтобы Вы запустили путем выполнения всего UI таким же образом, как Вы делаете теперь без внимания на удобство использования и материал.
сопроводительный текст http://www.stricken.org/uploaded_images/WordToolbars-718376.jpg
Теперь думает об этом:
разработчик А знает, что достиг совершенства не, когда нет ничего для добавления, а когда нет ничего для устранения. — Saint-ExupГ©ry
И применяют это в Вашем дизайне.
Много разработчиков думает, что, потому что они могут написать код, они могут сделать все это. Разработка интерфейса является совершенно другим навыком, и не преподавалось вообще, когда я ходил в школу. Это не просто что-то, что просто прибывает естественно.
Другая хорошая книга Дизайн Повседневных Вещей Donald Norman.
Существует огромная разница между дизайном и эстетикой, и они часто путаются.
А красивый UI требует артистических или по крайней мере эстетических навыков, что многие, включая меня, неспособны к созданию. К сожалению, это недостаточно и не делает UI применимым, как мы видим во многих тяжелых основанных на флэш-памяти API.
Производящий применимый UIs требует понимания того, как люди взаимодействуют с компьютерами, некоторыми проблемами в психологии (например, закон Fitt, закон Hick), и другие темы. Очень немного программ CS обучаются для этого. Очень немного разработчиков, которых я знаю, выберут тестирующую пользователя книгу по книге JUnit, и т.д.
, Многие из нас являются также "базовыми программистами", будучи склонен думать о UIs как о фасаде, а не как фактор, который мог решить судьбу успеха нашего проекта.
, Кроме того, большая часть опыта разработки UI чрезвычайно печальна. Мы можем или использовать игрушечных разработчиков GUI как старый VB и иметь для контакта с ужасным кодом связующего звена, или мы используем API, которые расстраивают нас ни к какому концу, как попытка разобраться в разметках в Swing.
Перейдите к Slashdot и прочитайте комментарии к любой статье, имеющей дело с Apple. Вы найдете большое количество людей, говорящих о том, как продуктами Apple является ничто специальное, и приписывание успеха iPod и iPhone людям, пытающимся быть модными или бедро. Они будут обычно проходить списки функций и указывать, что ничего не делают, более ранние MP3-плееры или смартфоны не сделали.
Затем существуют люди, которым нравятся iPod и iPhone, потому что они делают то, что пользователи хотят просто и легкий, независимо от руководств. Интерфейсы почти так интуитивны, как интерфейсы становятся, незабываемыми, и поддающимися обнаружению. Я столь же не люблю UI на MacOSX, как я был на более ранних версиях, я думаю, что они бросили некоторую полноценность в пользу блеска, но iPod и iPhone являются примерами превосходного дизайна.
, Если Вы находитесь в первом лагере, Вы не думаете способ, которым делает средний человек, и поэтому Вы, вероятно, сделаете плохие пользовательские интерфейсы, потому что Вы не можете сказать им от хороших. Это не означает, что Вы безнадежны, а скорее что необходимо явно изучить хорошие принципы дизайна интерфейса, и как распознать хороший UI (хотя кто-то с Asperger, возможно, должен был бы освоить социальные навыки явно). Очевидно, просто наличие смысла хорошего UI не означает, что можно сделать тот; моя оценка для литературы, например, кажется, не расширяется на способность (в настоящее время) для записи пригодных для печати историй.
Так, попытайтесь развить чувство для хорошего дизайна UI. Это расширяется на больше, чем просто программное обеспечение. Don Norman "Дизайн Повседневных Вещей" является классиком, и там существуют другие книги. Заставьте примеры успешных проектов UI и игры с ними достаточно получать ощущение различия. Распознайте, что необходимо изучить новый образ мыслей abou вещи, и обладать им.
Основное эмпирическое правило, которого я придерживаюсь, никогда не попытка сделать обоих сразу. Если я буду работать над кодом бэкенда, то я закончу выполнение этого, сделаю перерыв и возвращусь с моей шляпой UI на. При попытке работать он в том, пока Вы делаете код, Вы приблизитесь к нему с неправильным мышлением и закончите с некоторыми ужасными интерфейсами в результате.
я думаю, что определенно возможно быть и хорошим разработчиком бэкенда и хорошим разработчиком UI, Вы просто должны работать в нем, сделать некоторое чтение и исследование в области темы (все от № 7 Miller's, в архивы Nielsen), и удостоверяетесь, что понимаете , почему дизайн UI имеет наибольшее значение.
я не думаю, что это - случай необходимости быть творческим, а скорее, как разработка бэкенда, это - очень методическая, очень структурированная вещь, которая должна быть изучена. Это - люди, становящиеся 'творческим' с UIs, который создает некоторые самые большие чудовища удобства использования... Я имею в виду, смотрю на 100% веб-сайтов Flash для запуска...
Редактирование : книга Krug действительно хороша... берут чтение его, особенно если Вы собираетесь быть разработкой для сети.
Я пытаюсь поддержать контакт с определенными для дизайна веб-сайтами и текстами. Я нашел также превосходную книгу Robin Williams Книгой Дизайна Неразработчика, чтобы быть очень интересным в этих исследованиях.
я полагаю, что дизайн и удобство использования являются очень важной частью разработки программного обеспечения, и мы должны изучить это больше и прекратить давать оправдания, что мы, как предполагается, не делаем дизайн.
Все могут быть разработчиком время от времени, равно как и все могут быть программистом.
Когда приближающийся дизайн UI, вот несколько вещей, я имею в виду повсюду (далеко не полный список):
Передача модели . UI является рассказом, который объясняет умственную модель пользователю. Эта модель может быть бизнес-объектом, ряд отношений, что имеет Вас. Визуальное выдающееся положение, пространственное размещение и рабочий процесс, заказывая всем играют роль в передаче этой модели пользователю. Например, определенный вид списка по сравнению с другим подразумевает разные вещи, а также отношения того, что находится в списке к остальной части модели. В целом я нахожу, что он лучше всего удостоверяется, что только одна модель передается за один раз. Программисты часто пытаются передать больше чем одну модель или части нескольких, в том же пространстве UI.
Непротиворечивость . Многократное использование популярных метафор UI помогает много. Внутренняя непротиворечивость также очень важна.
Группировка задач . Пользователям не придется переместить мышь полностью через экран, чтобы проверить или завершить связанную последовательность команд. Модальные диалоговые окна и раскрывающие меню могут быть особенно плохими в этой области.
Знание Вашей аудитории . Если Ваши пользователи будут делать те же операции много раз, они быстро станут продвинутыми пользователями в тех задачах и расстроены попытками понизить начальный барьер записи. Если Ваши пользователи делают много различных видов операций нечасто, лучше гарантировать, что UI содержит их руку все время.
Читайте инструкции .
по интерфейсу пользователя AppleЯ нахожу, что лучший инструмент в дизайне UI должен наблюдать, что новый Пользователь пытается использовать программное обеспечение. Возьмите загрузки примечаний и задайте им некоторые вопросы. Никогда не направляйте их или пытайтесь объяснить, как программное обеспечение работает. Это - задание UI (и правильно написанная документация).
Мы последовательно принимаем этот подход во всех проектах. Это является всегда захватывающим, чтобы наблюдать, что Пользователь имеет дело с программным обеспечением способом, который Вы никогда не рассматривали прежде.
, Почему дизайн UI настолько трудно? Хорошо обычно, потому что Разработчик и Пользователь никогда не встречаются.
Я знаю, что Microsoft довольно несовместима с их собственными инструкциями, но я нашел, что чтение их руководства по проектированию Windows действительно помогло мне. Я имею копию на своем веб-сайте здесь , просто прокручиваю немного вниз Руководство UX Vista. Это помогло мне с вещами, такими как цвета, интервал, разметки, и т.д.
duffymo просто напомнил мне почему: Многие Программисты думают "*Design" == "Статья"
, Хороший дизайн UI абсолютно не профессионален. Это следует за твердыми принципами, которые могут быть сохранены с данными, если у Вас есть время для проведения исследования.
я думаю, что все программисты должны сделать, занимают время для изучения принципов. Я думаю, что это находится в нашем характере для применения лучшей практики каждый раз, когда мы можем, быть этим в коде или в расположении. Все, что мы должны сделать, делают нас знающий, что лучшие практики для этого аспекта нашего задания.
Я полагаю, что основная проблема не имеет никакого отношения к различным талантам или наборам навыков. Основная проблема состоит в том, что как разработчик, Вы знаете слишком много о том, что делает приложение и как оно делает это, и Вы автоматически разрабатываете свой UI с точки зрения кого-то, у кого есть то знание.
принимая во внимание, что пользователь обычно начинает абсолютно ничего не знать о приложении и никогда не должен должен быть узнавать что-либо о его внутренних работах.
Это очень твердо, почти невозможно, для не использования знания, что Вы имеете - и вот почему UI не должен быть разработан кем-то, кто разрабатывает приложение позади него.
"Разработка с обеих сторон экрана" представляет очень простую, но глубокую причину относительно того, почему программисты находят, что UI разрабатывает трудно: программисты обучены думать с точки зрения пограничных случаев, в то время как разработчики UI обучены думать с точки зрения общих падежей или использования.
Настолько идущий от одного мира до другого является, конечно, трудным, если значение по умолчанию traning в любом является полной противоположностью другого.
Что я сделал для становления лучше в дизайне UI?
Обращают внимание на него!
Это похоже, как когда-нибудь время, Вы видите диаграмму на новостях или электронном знаке шины и Вы задаетесь вопросом, 'Как они получали те данные? Они делали это с сырыми данными sql, или они используют LINQ?' (или вставляют Ваше собственное общее любопытство фаната здесь).
необходимо начать делать это, но с визуальными элементами всех видов.
, Но точно так же, как изучение нового языка, если Вы не делаете действительно бросок сами в него, Вы никогда не будете изучать это.
Взятый от другой ответ я записал:
Учатся смотреть, действительно посмотрите в мире вокруг Вас. Почему я люблю тот UI, но ненавижу этого? Почему настолько трудно найти тарелки лапши в этом меню ресторана? Ничего себе, я знал то, что означал тот знак, прежде чем я даже считал слова. Почему это было? Каким образом та обложка книги выглядит настолько неправильной? Учитесь не торопиться для размышления о том, почему Вы реагируете способ, которым Вы делаете к визуальным элементам всех видов и затем применяете это к своей работе.
К вопросу:
почему так труден дизайн UI для большинства разработчиков?
Попытайтесь задать обратный вопрос:
почему программирует настолько трудный для большинства разработчиков UI?
Кодирование UI и разработка UI требуют различных навыков и другого мышления. Дизайн UI труден для большинства разработчиков, не некоторых разработчиков, как написание кода трудно для большинства разработчиков, не некоторых разработчиков.
Кодирование трудно. Дизайн труден также. Немного людей делают обоих хорошо. Хорошие разработчики UI редко пишут код. Они даже не могут знать, как, все же они - все еще хорошие разработчики. Итак, почему хорошие разработчики чувствуют себя ответственными за дизайн UI?
Знание больше о дизайне UI сделает Вас лучшим разработчиком, но это не означает, что необходимо быть ответственны за дизайн UI. Реверс верен для разработчиков: знание, как написать код, сделает их лучшими разработчиками, но это не означает, что они должны быть ответственны за кодирование UI.
Для разработчиков, желающих поправляться в UI, разрабатывают, у меня есть 3 основных совета:
Вот некоторые определенные вещи, которые можно изучить. Не пытайтесь изучить все. Если Вы знали, что все ниже Вас могло бы назвать себя разработчиком взаимодействия или информационным архитектором. Запустите с вещей около верхней части списка. Внимание на определенные понятия и навыки. Затем спуститесь и расширьтесь. Если Вы действительно любите этот материал, рассматриваете это как карьеру. Многие разработчики перемещаются в управления, но дизайн UX является другой опцией.
Хороший дизайн UI труден, потому что он включает 2 весьма различных навыков:
Это - существенное различие между этими 2 группами — между разработчиками и разработчиками:
Кроме того, программирование и дизайн требует различных мышлений, не только другого знания и различных навыков. Хороший дизайн UI требует обоих мышлений, обеих баз знаний, обеих групп навыка. И требуются годы для освоения любого.
Разработчики должны ожидать находить, что UI разрабатывает трудно, так же, как разработчики UI должны ожидать находить написание кода трудно.
Для этого есть много причин.
(1) Разработчик не видит вещей с точки зрения пользователя. Это обычный подозреваемый: отсутствие сочувствия. Но обычно это не так, потому что разработчики не такие чуждые, как их себе представляют.
(2) Другая, более распространенная причина заключается в том, что разработчик, который так близок к своим вещам, так долго оставался со своими вещами, не понимает, что его вещи могут быть не такими знакомыми (термин лучше, чем интуитивно понятный) другим людям.
(3) Еще одна причина - отсутствие у разработчика техники.
МОЕ БОЛЬШОЕ ЗАЯВЛЕНИЕ: прочтите любой пользовательский интерфейс, дизайн взаимодействия с человеком, книгу по прототипированию. например Проектирование очевидного: здравый смысл в дизайне веб-приложений, не заставляйте меня думать: здравый подход к веб-юзабилити, проектирование момента, что угодно.
Как они обсуждают потоки задач? Как они описывают точки принятия решения? То есть в любом случае существует как минимум 3 пути: успех, сбой / исключение, альтернатива.
Таким образом, из точки A можно перейти к A.1, A.2, A.3. Из точки A.1 вы можете добраться до A.1.1, A.1.2, A.1.3 и так далее.
Как они показывают такую детализированную последовательность задач? Они этого не делают. Они просто замалчивают это.
Поскольку даже у экспертов по пользовательскому интерфейсу нет техники, у разработчиков нет шансов.Он думает, что это ясно в его голове. Но это непонятно даже на бумаге, не говоря уже о программной реализации.
Я должен использовать для этого свои собственные техники ручной работы.
Как бы вы это ни делали (и есть несколько замечательных моментов выше), это действительно помогло мне, когда я согласился с тем, что НЕТ ТАКОГО ИНТУИТИВНОГО НЕТ ....
Я слышу, как аргументы грохочут на горизонте .. Итак, позвольте мне немного объяснить.
Интуитивный: использование того, что кажется правильным или истинным, на основе бессознательного метода или чувства.
Если (как постулировал Карл Саган) вы соглашаетесь с тем, что не можете постичь вещи, которые абсолютно не похожи ни на что из того, с чем вы когда-либо сталкивались, то как вы могли «знать», как использовать что-то, если вы никогда не использовали ничего отдаленно похожего?
Подумайте об этом: дети пытаются открывать двери не потому, что они «знают», как работает дверная ручка, а потому, что они видели, как это делает кто-то другой ... часто они поворачивают ручку в неправильном направлении или слишком рано тянут ручку. Они должны УЗНАТЬ, как работает дверная ручка. Затем эти знания применяются в разных, но похожих случаях: открытие окна, открытие ящика, открытие почти всего большого с помощью большой ручки, похожей на ручку.
Даже простые вещи, которые кажутся нам интуитивными, не будут интуитивно понятны людям из других культур. Если кто-то протянул руку перед собой и взмахнул рукой вверх-вниз на запястье, при этом держа руку неподвижной… они отталкивают вас? Наверное, если вы не в Японии. Здесь этот сигнал рукой может означать «иди сюда». Так кто же прав? Оба, конечно, в своем собственном контексте. Но если вы путешествуете по обоим, вам нужно знать и то, и другое ... Дизайн пользовательского интерфейса.
Я пытаюсь найти то, что уже «знакомо» потенциальным пользователям моего проекта, а затем строю вокруг них пользовательский интерфейс: дизайн, ориентированный на пользователя.
Взгляните на iPhone от Apple. Даже если вы ненавидите это, вы должны уважать количество мыслей, которые были вложены в него. Это идеально? Конечно, нет. Со временем воспринимаемая «интуитивность» объекта может вырасти или даже полностью исчезнуть.
Например. Практически все знают, что черная полоса с двумя рядами отверстий сверху и снизу выглядит как пленка ... или не так ли?
Спросите своего среднего 9-10-летнего ребенка, что они думают об этом. Вы можете быть удивлены, сколько детей прямо сейчас будет трудно идентифицировать это как киноленту, даже если это что-то, что до сих пор используется для представления Голливуда или чего-либо, связанного с фильмом (фильмом). Большинство фильмов за последние 20 лет было снято в цифровом формате. И когда в последний раз кто-либо из нас держал в руках фильм ЛЮБОГО вида, фотографии или пленки?
Итак, для меня все сводится к следующему: знай свою аудиторию и постоянно исследуй, чтобы не отставать от тенденций и изменений. в вещах, которые являются «интуитивными», ориентируйтесь на своих основных пользователей и старайтесь не делать того, что наказывает неопытных в пользу продвинутых пользователей или замедляет продвинутых пользователей, чтобы держать новичков в руках.
В конечном счете, каждая программа потребует определенного обучения со стороны пользователя, чтобы использовать ее. Сколько обучения и для какого уровня пользователя - это часть решений, которые необходимо принять.
Некоторые вещи более или менее знакомы, исходя из прошлого опыта вашего целевого пользователя в качестве человека, пользователя компьютера, студента или кого-то еще.
Я просто стремлюсь к самой толстой части кривой и стараюсь привлечь как можно больше людей, но понимая, что я никогда не буду всем угодить ....
Сказать, что программы сосут при дизайне UI, означает упустить суть. Точка проблемы - то, что формальное обучение, которое получает большинство разработчиков, идет всестороннее с технологией. Человек - Компьютерное Взаимодействие не является простой темой. Это не что-то, что я могу "комбинация ума" Вам путем обеспечения простого одного оператора строки, который заставляет Вас понять, "что, о, пользователи будут использовать это приложение эффективнее, если я сделаю x вместо y".
Это вызвано тем, что существует одна часть дизайна UI, который Вы пропускаете. Человеческий мозг. Чтобы понять, как разработать UI, необходимо понять, как человеческий разум взаимодействует с оборудованием. Существует превосходный курс, который я взял в Миннесотском университете этой темы, преподававшей преподавателем Психологии. Это называют "Человеком - Взаимодействие Машины". Это описывает многие причины того, почему дизайн UI является так сложным.
, Так как Психология основана на Корреляциях и не Причинной связи, Вы никогда не можете доказывать, что метод дизайна UI будет всегда работать в любой данной ситуации. Можно коррелировать это, многие пользователи найдут конкретное обращение дизайна UI или эффективный, но Вы не можете доказать, что оно будет всегда делать вывод.
Кроме того, существует две части к дизайну UI, который многие люди, кажется, пропускают. Существует эстетическое обращение и функциональный рабочий процесс. Если Вы пойдете для 100%-го эстетического обращения, то верные люди будут, но Ваш продукт. Я высоко сомневаюсь, что эстетика будет когда-либо уменьшать пользовательское разочарование все же.
существует несколько хороших книг по этой теме и курсу для взятия (как Bill Buxton Пользовательские События Рисования эскизов , и Познание в Дикой природе Edwin Hutchins). Существуют программы специализации на Человеке - Компьютерное Взаимодействие во многих университетах.
полный ответ на этот вопрос, хотя находится в том, как людям преподают информатику. Это - вся базирующаяся математика, базирующаяся логика а не на основе пользовательского опыта. Для получения этого Вам нужны больше, чем универсальный 4-летний градус информатики (если Ваш 4-летний градус информатики не имел несовершеннолетнего в психологии и был подчеркнут в Человеке - Компьютерное Взаимодействие).
Давайте изменим к лучшему Ваш вопрос -
, "ui разработчики", обреченные только разработать информационную архитектуру и уровни представления? Есть ли что-то, что они могут сделать для переквалификации их мозгов, чтобы быть более эффективными при разработке приятных и эффективных системных слоев?
Походит на них "ui, разработчики" должны были бы взять совершенно другую перспективу - они должны будут посмотреть с внутренней части поля за пределы; вместо того, чтобы заглянуть снаружи поля.
Alan Cooper "Обитатели Выполняет Убежище" , мнение - то, что мы не можем успешно взять обе перспективы - мы можем учиться носить одну шляпу хорошо, но мы не можем только переключить шляпы.
Я думаю, потому что хороший UI не логичен. Хороший UI интуитивен.
Разработчики программного обеспечения обычно делают плохо на 'интуитивном'
Полезное структурирование должно активно рассмотреть то, что Вы делаете как разработка процесса коммуникации. В очень реальном смысле Ваш интерфейс является языком, который пользователь должен использовать для сообщения компьютера, что сделать. Это приводит к рассмотрению ряда вопросов:
Действительно, несколько трудно определить, какие программисты думают об интерфейсном взаимодействии, как являющемся, другой , чем процесс коммуникации, но возможно проблема состоит в том, что это не получает мысль как являющийся ничем вообще.
Уже существует много o хороших комментариев, таким образом, я не уверен, что существует очень, я могу добавить. Но все еще...
Мы не ожидаем что случайный "Joe водопроводчик" мочь написать хороший код. Итак, почему мы ожидали бы, что случайный "Joe программист" разработает хороший UI?
Сочувствие помогает. Разделение дизайна UI и программирования помогает. Тестирование удобства пользования помогает.
, Но дизайн UI ремесло, которое должно быть изучено и осуществлено, как любой другой.
Разработчики не (обязательно) хороши в дизайне UI по той же причине, они не (обязательно) хороши в вязании; это твердо, это берет практику, и не повреждает сделать, чтобы кто-то показал Вам как во-первых.
Большинство разработчиков (меня включенный) начало "разрабатывать" UIs, потому что это была необходимая часть записи программного обеспечения. Пока разработчик не вставит усилие стать хорошим в нем, он или она не будет.
Для улучшения просто озираются на существующих сайтах. В дополнение к книгам, уже предложенным, Вы хотели бы взглянуть на превосходную книгу Robin Williams "Книга Дизайна Неразработчиков" ( санированная ссылка Amazon )
, Взглянули на то, что возможно в визуальном проектировании путем взгляда на различные представления, законченные в Zen-Garden также.
дизайн UI является определенно искусством, хотя, как указатели в C, некоторые люди получают его, и некоторые люди не делают.
, Но по крайней мере у нас может быть хихиканье при их попытках . BTW Спасибо OK/отмена для забавного комика и благодарна за то, что Joel помещает его в Вашу книгу "Лучшее программное обеспечение, Пишущий I" ( санированная ссылка Amazon ).
Пользовательский интерфейс не что-то, что может быть применено после факта, как тонкий слой краски. Это - что-то, что должно быть там в запуске, и на основе реального исследования. Существуют тонны исследования Удобства использования, доступного, конечно. Это не должно только быть там в запуске, это должно сформировать ядро самой причины, Вы делаете программное обеспечение во-первых: существует некоторый разрыв в мире там, некоторая проблема, и это должно быть сделано более применимым и более эффективным.
программное обеспечение не там ради самого себя. Причина части программного обеспечения для существования ДЛЯ ЛЮДЕЙ. Это абсолютно смехотворно, чтобы даже попытаться придумать идею для новой части программного обеспечения, не понимая, почему любому был бы нужен он. Все же это происходит все время.
, Прежде чем одна строка кода записана, необходимо пройти бумажные версии интерфейса и протестировать его на настоящих людях. Это довольно странно и глупо, это работает лучше всего с детьми и кем-то интересное действие как "компьютер".
интерфейс должен использовать в своих интересах наши естественные познавательные средства. Как пещерный человек использовал бы Вашу программу? Например, мы развились, чтобы быть действительно хорошими в отслеживании движущихся объектов. Вот почему интерфейсы, которые используют моделирования физики, как iPhone, работают лучше, чем интерфейсы, где изменения происходят мгновенно.
Мы способны к определенным видам абстракции, но не другим. Как программисты, мы обучены сделать умственную гимнастику и перевороты назад для понимания некоторых самых странных абстракций. Например, мы понимаем, что последовательность тайного текста может представить и быть переведена в шаблон электромагнитного состояния на металлическом диске, который при обнаружении тщательно разработанным устройством приводит к последовательности невидимых событий, которые происходят в lightspeed на электронной схеме, и эти события могут быть предписаны произвести полезный результат. Это - невероятно неестественная вещь должным быть понять. Поймите, что, в то время как это имеет совершенно рациональное объяснение нам к внешнему миру, похоже, что мы пишем непостижимые заклинания для вызова невидимых разумных духов для выполнения наших указаний.
виды абстракций, которые понимают нормальные люди, являются вещами как карты, схемы и символы. Остерегайтесь символов, потому что символы являются очень хрупким человеческим понятием, которые прилагают сознательные умственные усилия для декодирования, пока символ не изучен.
прием с символами - то, что должны быть ясные отношения между символом и вещью, которую это представляет. Вещью это представляет любого, должно быть существительное, в этом случае символ должен ОЧЕНЬ походить на вещь, которую это представляет. Если символ представляет более абстрактное понятие, которое должно быть объяснено ЗАРАНЕЕ. Посмотрите непостижимые unlabled значки в MSWord, или панель инструментов фотошопа и абстрактные понятия, которые они представляют. Нужно ИЗУЧИТЬ, что значок инструмента обрезки в фотошопе означает ИНСТРУМЕНТ ОБРЕЗКИ. нужно подразумевать, что ОБРЕЗАЕТ даже средства. Это предпосылки к корректному использованию того программного обеспечения. Который поднимает важный момент, остерегайтесь ПРИНЯТОГО знания.
Мы только получаем способность понять карты вокруг возраста 4. Я думаю, что читал где-нибудь однажды тот, шимпанзе получают способность понять карты вокруг возраста 6 или 7.
причина, что guis были так успешны для начала, состоит в том, что они изменили среду главным образом текстовых интерфейсов к компьютерам к чему-то, что отобразило компьютерные понятия на что-то, что напомнило физическое место. Где сбой guis с точки зрения удобства использования, то, где они прекращают напоминать что-то, что Вы видели бы в реальной жизни. Существуют невидимые, непредсказуемые, непостижимые вещи, которые происходят в компьютере, который пустой никакое подобие чему-либо Вы когда-либо видели бы в материальном мире. Часть этого необходима, так как не было бы никакого смысла в просто делании реальностью средства моделирования - идея состоит в том, чтобы сохранить работу, таким образом, должно быть немного волшебства. Но то волшебство должно иметь смысл и быть основано в абстракции, что люди хорошо адаптированы к пониманию. Это - когда наши абстракции начинают становиться глубокими, и разделенными на уровни и не соответствовавшими с задачей под рукой, что вещи ломаются. Другими словами, интерфейс не функционирует как хорошую карту для базового программного обеспечения.
существует много книг. Два я читал, и может поэтому reccomend, быть "Дизайном Повседневных Вещей" donald нормандцем, и "Интерфейсом пользователя" Jef Raskin.
я также reccomend курс в психологии. "Дизайн Каждого дня Вещи" говорит об этом немного. Много интерфейсов ломается из-за "народного понимания разработчика" психологии. Это подобно "народной физике". Объект в движении остается в движении, не имеет никакого смысла большинству людей. "Необходимо продолжать продвигать это сохранять его в движении!" думает новичок физики. Пользователь, тестирующий, не имеет смысла большинству разработчиков. "Можно просто спросить пользователей, что они хотят, и это должно быть достаточно хорошо!" думает новичок психологии.
я reccomend Обнаружение Психологии, документального сериала PBS, размещается Philip Zimbardo. Сбой этого, попытайтесь найти хороший учебник по физике. Дорогой вид. Не чтиво сам помогает дерьму, которое Вы находите в Границах, но толстом материале в твердом переплете, который можно только найти в университетской библиотеке. Это - necesesary основа. Можно сделать хороший дизайн без него, но у Вас только будет интуитивное понимание того, что продолжается. Чтение некоторых хороших книг даст Вам хорошую перспективу.
При чтении книги, "Почему программное обеспечение сосет", Вы видели бы ответ Platt, который является простым:
, Но другой другой ответ на Ваш вопрос, был бы, "почему так трудна стоматология для некоторых разработчиков?" - дизайн UI лучше всего сделан разработчиком UI.
http://dotmad.net/blog/2007/11/david-platt-on-why-software-sucks/