Почему так труден хороший дизайн UI для некоторых Разработчиков? [закрытый]

Ваш 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)

206
задан 13 revs, 3 users 100% 6 November 2018 в 15:05
поделиться

64 ответа

Позвольте мне сказать это непосредственно:

Изменение к лучшему этого не начинается с инструкций. Это начинается с переструктурирования, как Вы думаете о программном обеспечении.

Большинство жестких разработчиков имеет практически нулевое сочувствие к пользователям их программного обеспечения. Они имеют никакая подсказка , как пользователи думают, как пользователи создают модели программного обеспечения, которое они используют и как они используют компьютер в целом.

Это - типичная проблема, когда эксперт сталкивается с неспециалисты: Как же нормальный человек мог быть так немой для не понимания то, что эксперт понял 10 лет назад?

Один из первых фактов, которые подтвердят, который это невероятно трудно схватить почти для всех опытных разработчиков, является этим:

у Нормальных людей есть весьма другое понятие программного обеспечения, чем Вы имеете. У них нет подсказки вообще программирования.Ничего. Нуль. И они даже не заботятся. Они даже не думают, что должны заботиться. Если Вы вынудите их к, то они удалят Вашу программу.

Теперь это невероятно резко для разработчика. Он гордится программным обеспечением, которое он производит. Он любит каждую функцию. Он может сказать Вам точно, как код позади него работает. Возможно, он даже изобрел невероятный умный алгоритм, который заставил его работать на 50% быстрее, чем прежде.

И пользователь не заботится.

, Что идиот.

Многие разработчики не могут выдержать работать с обычными пользователями. Они подавлены их неимеющимися знаниями технологии. И вот почему большинство разработчиков уклоняется и думает, что пользователи должны быть идиотами.

Они не.

, Если разработчик программного обеспечения покупает автомобиль, он ожидает, что это будет работать гладко. Он обычно не заботится о давлении в шине, механическое устройство, подстраивающее, который был важен, чтобы заставить его выполнить тот путь. Здесь он не эксперт. И если он покупает автомобиль, который не имеет подстройки, он отдает ее и покупает ту, которая делает то, что он хочет.

Многие разработчики программного обеспечения как фильмы. Хорошо сделанные фильмы, которые зажигают их воображение. Но они не эксперты в создании фильмов в произведении визуальных эффектов или в записи хороших сценариев фильма. Большинство компьютерных фанатов очень, очень, очень плохо при действии, потому что это - все об отображении сложных эмоций и мало об аналитике. Если разработчик смотрит плохой фильм, он просто замечает, что это плохо в целом. Компьютерные фанаты даже создали IMDb для сбора информации о хороших и плохих фильмах, таким образом, они знают, которые смотреть и чтобы избежать. Но они не эксперты в создании фильмов. Если фильм будет плох, то они не пойдут в кино (или не загрузят его с БитТоррента ;)

, Таким образом, он сведется к: Избегание обычных пользователей как эксперт незнание. , поскольку в тех областях (и существуют так многие), где они не эксперты, они ожидают, что эксперты других областей будут уже думать о нормальных людях, которые используют их продукты или услуги.

, Что можно сделать для исправления его? Чем более жесткие Вы как программист, тем менее открыты Вы будете для обычного пользователя, думающего. Это будет посторонним и невежественным Вам. Вы будете думать: Я не могу вообразить, как люди могли когда-либо , используют компьютер с этим отсутствием знаний. Но они могут. Для каждого элемента UI думайте о: действительно ли это необходимо? Это соответствует к понятию, которое пользователь имеет моего инструмента? Как я могу заставить его понять? Читайте на удобстве использования для этого, существует много хороших книг. Это - целая область науки, также.

А-ч и перед высказыванием этого, да, я - поклонник Apple ;)

360
ответ дан Chris Ballance 23 November 2019 в 04:46
поделиться

Что действительно помогает мне улучшиться, мой дизайн должен захватить такого же разработчика, один парни QA, премьер-министр или любой, кто, оказывается, идет и сделал, чтобы они испытали конкретный виджет или экран.

Его удивительное, что Вы поймете, когда Вы будете наблюдать, что кто-то еще использует Ваше программное обеспечение впервые

70
ответ дан Kevin 23 November 2019 в 04:46
поделиться

В конечном счете это действительно о сочувствии - можно ли поместить себя в обувь Вашего пользователя?

Одна вещь, которая помогает, конечно, "ест Ваш собственный собачий корм" - использование Ваших приложений как реальный пользователь самостоятельно и наблюдение, что является раздражающим.

Другая хорошая идея состоит в том, чтобы найти способ наблюдать за реальным пользователем, использующим Ваше приложение, которое может быть столь же сложным как лаборатория удобства использования с односторонними зеркалами, экранной видеосъемкой, видеокамерами на пользователях, и т.д., или может быть столь же простым как бумажная разработка прототипа с помощью следующего человека, который, оказывается, спускается с Холла.

, Если все остальное перестало работать, помните, что для UI почти всегда лучше быть слишком простым, чем слишком сложный. Очень очень легко сказать, "о, я знаю, как решить это, я просто добавлю флажок, таким образом, пользователь сможет решить, какой режим они предпочитают". Скоро Ваш UI является слишком сложным. Выберите режим по умолчанию и установите предпочтительную настройку усовершенствованный параметр конфигурации. Или просто пропустите его.

, Если Вы читаете много о дизайне, можно легко стать одержимыми отброшенными тенями и скругленными углами и т.д. Это не важный материал. Простота и discoverability являются важным материалом.

32
ответ дан Jacob Mattison 23 November 2019 в 04:46
поделиться

Вопреки популярному мифу в дизайне UI нет буквально никаких мягких аспектов, по крайней мере не больше, чем должен был разработать хороший бэкэнд.

Рассматривают следующее; хороший дизайн бэкэнда основан на довольно твердых принципах и элементах, с которыми любой хороший разработчик знаком:

  • слабая связь

  • высокая связность

  • архитектурные шаблоны

  • промышленные лучшие практики

  • и т.д.

Хороший дизайн бэкэнда обычно рождается через многие взаимодействия, где на основе измеримой обратной связи, полученной во время тестов или фактического использования, начальный проект постепенно улучшается. Иногда необходимо моделировать меньшие аспекты бэкэнда и испытать их в изоляции и т.д.

, Хороший дизайн UI основан на звуковых принципах:

  • видимость

  • подразумеваемая возможность

  • обратная связь

  • допуск

  • простота

  • непротиворечивость

  • структура

UI также рождается через тест и пробную версию, посредством повторений, но не с компилятором + автоматизированный тестовый иск, но люди. Так же к бэкэнду существуют промышленные методы наиболее успешной практики, измерение и методы оценки, способы думать о UI и установить цели с точки зрения пользовательской модели, образа системы, модели разработчика, структурной модели, функциональная модель и т.д.

, набор навыков, необходимый для разработки UI, очень отличается от разработки бэкенда, и следовательно don’t ожидают мочь сделать хороший UI, не делая некоторого изучения сначала. Однако то, что обе этих операции имеют общего, является процессом дизайна. Я полагаю, что любой, кто может разработать хорошее программное обеспечение, способен к разработке хорошего UI, пока они проводят некоторое время, учась как.

я рекомендую брать курс в Человеко-машинном взаимодействии, проверяю MIT и Йельский сайт, например, для материалов онлайн:

Структурный по сравнению с Функциональной моделью в Понимании и Использовании

превосходное ранее сообщение Thorsten79 поднимает тему экспертов по разработке программного обеспечения по сравнению с пользователями и как их понимание программного обеспечения отличается. Эксперты по изучению - люди различают функциональные и структурные умственные модели. Нахождение пути к дому Вашего друга может быть превосходным примером различия между двумя:

  • Первый подход включает ряд подробных инструкций: возьмите первый выход автострады, затем после того, как 100 ярдов повернут налево и т.д. Это - пример функциональной модели: список конкретных шагов, необходимых для достижения определенной цели. Функциональные модели просты в использовании, они не требуют больших взглядов просто прямое выполнение. Очевидно, существует штраф за простоту: это не мог бы быть наиболее эффективный маршрут, и любая любая исключительная ситуация (т.е. транспортная диверсия) может легко привести к полному отказу.

  • А другой способ справиться с задачей состоит в том, чтобы создать структурную умственную модель. В нашем примере, который был бы картой, которая передает большую информацию о внутренней структуре "объекта задачи". От понимания карты и относительных местоположений дома нашего и друга мы можем вычесть функциональную модель (маршрут). Очевидно, это, требует большего усилия, но намного более надежного способа выполнить задачу несмотря на возможные отклонения.

выбор между передачей функциональной или структурной модели через UI (например, мастер по сравнению с расширенным режимом) не состоит в том, что прямой, поскольку это могло бы казаться из сообщения Thorsten79. Усовершенствованные и частые пользователи могли бы хорошо предпочесть структурную модель, тогда как случайные или менее опытные пользователи — функциональный.

Google отображается, яркий пример: они включают и функциональную и структурную модель, сделайте многие сидели navs.

Другой размер проблемы - то, что структурная модель, представленная через UI, не должна отображаться на структуру программного обеспечения, а скорее естественно отображаться на структуру пользовательской задачи под рукой или включенного объекта задачи.

трудность здесь состоит в том, что у многих разработчиков будет хорошая структурная модель их внутренностей программного обеспечения, но только функциональная модель пользователя определяет задачу для целей программного обеспечения помочь в. Для создания хорошего UI, нужно понять структуру задачи/объекта задачи и отобразить UI на ту структуру.

Так или иначе, я все еще не могу рекомендовать брать формальный курс HCI достаточно сильно. Существует много материала, включенного такой как эвристика , принципы, полученные от гештальт phychology , способы, которыми люди учатся и т.д.

26
ответ дан Community 23 November 2019 в 04:46
поделиться

Я предлагаю, чтобы Вы запустили путем выполнения всего UI таким же образом, как Вы делаете теперь без внимания на удобство использования и материал.

сопроводительный текст http://www.stricken.org/uploaded_images/WordToolbars-718376.jpg

Теперь думает об этом:

разработчик А знает, что достиг совершенства не, когда нет ничего для добавления, а когда нет ничего для устранения. — Saint-ExupГ©ry

И применяют это в Вашем дизайне.

25
ответ дан 2 revs 23 November 2019 в 04:46
поделиться

Много разработчиков думает, что, потому что они могут написать код, они могут сделать все это. Разработка интерфейса является совершенно другим навыком, и не преподавалось вообще, когда я ходил в школу. Это не просто что-то, что просто прибывает естественно.

Другая хорошая книга Дизайн Повседневных Вещей Donald Norman.

16
ответ дан F'x 23 November 2019 в 04:46
поделиться

Существует огромная разница между дизайном и эстетикой, и они часто путаются.

А красивый UI требует артистических или по крайней мере эстетических навыков, что многие, включая меня, неспособны к созданию. К сожалению, это недостаточно и не делает UI применимым, как мы видим во многих тяжелых основанных на флэш-памяти API.

Производящий применимый UIs требует понимания того, как люди взаимодействуют с компьютерами, некоторыми проблемами в психологии (например, закон Fitt, закон Hick), и другие темы. Очень немного программ CS обучаются для этого. Очень немного разработчиков, которых я знаю, выберут тестирующую пользователя книгу по книге JUnit, и т.д.

, Многие из нас являются также "базовыми программистами", будучи склонен думать о UIs как о фасаде, а не как фактор, который мог решить судьбу успеха нашего проекта.

, Кроме того, большая часть опыта разработки UI чрезвычайно печальна. Мы можем или использовать игрушечных разработчиков GUI как старый VB и иметь для контакта с ужасным кодом связующего звена, или мы используем API, которые расстраивают нас ни к какому концу, как попытка разобраться в разметках в Swing.

14
ответ дан Uri 23 November 2019 в 04:46
поделиться

Перейдите к Slashdot и прочитайте комментарии к любой статье, имеющей дело с Apple. Вы найдете большое количество людей, говорящих о том, как продуктами Apple является ничто специальное, и приписывание успеха iPod и iPhone людям, пытающимся быть модными или бедро. Они будут обычно проходить списки функций и указывать, что ничего не делают, более ранние MP3-плееры или смартфоны не сделали.

Затем существуют люди, которым нравятся iPod и iPhone, потому что они делают то, что пользователи хотят просто и легкий, независимо от руководств. Интерфейсы почти так интуитивны, как интерфейсы становятся, незабываемыми, и поддающимися обнаружению. Я столь же не люблю UI на MacOSX, как я был на более ранних версиях, я думаю, что они бросили некоторую полноценность в пользу блеска, но iPod и iPhone являются примерами превосходного дизайна.

, Если Вы находитесь в первом лагере, Вы не думаете способ, которым делает средний человек, и поэтому Вы, вероятно, сделаете плохие пользовательские интерфейсы, потому что Вы не можете сказать им от хороших. Это не означает, что Вы безнадежны, а скорее что необходимо явно изучить хорошие принципы дизайна интерфейса, и как распознать хороший UI (хотя кто-то с Asperger, возможно, должен был бы освоить социальные навыки явно). Очевидно, просто наличие смысла хорошего UI не означает, что можно сделать тот; моя оценка для литературы, например, кажется, не расширяется на способность (в настоящее время) для записи пригодных для печати историй.

Так, попытайтесь развить чувство для хорошего дизайна UI. Это расширяется на больше, чем просто программное обеспечение. Don Norman "Дизайн Повседневных Вещей" является классиком, и там существуют другие книги. Заставьте примеры успешных проектов UI и игры с ними достаточно получать ощущение различия. Распознайте, что необходимо изучить новый образ мыслей abou вещи, и обладать им.

12
ответ дан David Thornley 23 November 2019 в 04:46
поделиться

Основное эмпирическое правило, которого я придерживаюсь, никогда не попытка сделать обоих сразу. Если я буду работать над кодом бэкенда, то я закончу выполнение этого, сделаю перерыв и возвращусь с моей шляпой UI на. При попытке работать он в том, пока Вы делаете код, Вы приблизитесь к нему с неправильным мышлением и закончите с некоторыми ужасными интерфейсами в результате.

я думаю, что определенно возможно быть и хорошим разработчиком бэкенда и хорошим разработчиком UI, Вы просто должны работать в нем, сделать некоторое чтение и исследование в области темы (все от № 7 Miller's, в архивы Nielsen), и удостоверяетесь, что понимаете , почему дизайн UI имеет наибольшее значение.

я не думаю, что это - случай необходимости быть творческим, а скорее, как разработка бэкенда, это - очень методическая, очень структурированная вещь, которая должна быть изучена. Это - люди, становящиеся 'творческим' с UIs, который создает некоторые самые большие чудовища удобства использования... Я имею в виду, смотрю на 100% веб-сайтов Flash для запуска...

Редактирование : книга Krug действительно хороша... берут чтение его, особенно если Вы собираетесь быть разработкой для сети.

10
ответ дан James B 23 November 2019 в 04:46
поделиться

Я пытаюсь поддержать контакт с определенными для дизайна веб-сайтами и текстами. Я нашел также превосходную книгу Robin Williams Книгой Дизайна Неразработчика, чтобы быть очень интересным в этих исследованиях.

я полагаю, что дизайн и удобство использования являются очень важной частью разработки программного обеспечения, и мы должны изучить это больше и прекратить давать оправдания, что мы, как предполагается, не делаем дизайн.

Все могут быть разработчиком время от времени, равно как и все могут быть программистом.

7
ответ дан Edwin Jarvis 23 November 2019 в 04:46
поделиться

Когда приближающийся дизайн UI, вот несколько вещей, я имею в виду повсюду (далеко не полный список):

  • Передача модели . UI является рассказом, который объясняет умственную модель пользователю. Эта модель может быть бизнес-объектом, ряд отношений, что имеет Вас. Визуальное выдающееся положение, пространственное размещение и рабочий процесс, заказывая всем играют роль в передаче этой модели пользователю. Например, определенный вид списка по сравнению с другим подразумевает разные вещи, а также отношения того, что находится в списке к остальной части модели. В целом я нахожу, что он лучше всего удостоверяется, что только одна модель передается за один раз. Программисты часто пытаются передать больше чем одну модель или части нескольких, в том же пространстве UI.

  • Непротиворечивость . Многократное использование популярных метафор UI помогает много. Внутренняя непротиворечивость также очень важна.

  • Группировка задач . Пользователям не придется переместить мышь полностью через экран, чтобы проверить или завершить связанную последовательность команд. Модальные диалоговые окна и раскрывающие меню могут быть особенно плохими в этой области.

  • Знание Вашей аудитории . Если Ваши пользователи будут делать те же операции много раз, они быстро станут продвинутыми пользователями в тех задачах и расстроены попытками понизить начальный барьер записи. Если Ваши пользователи делают много различных видов операций нечасто, лучше гарантировать, что UI содержит их руку все время.

7
ответ дан Rex M 23 November 2019 в 04:46
поделиться

Читайте инструкции .

по интерфейсу пользователя Apple
7
ответ дан Marco Luglio 23 November 2019 в 04:46
поделиться

Я нахожу, что лучший инструмент в дизайне UI должен наблюдать, что новый Пользователь пытается использовать программное обеспечение. Возьмите загрузки примечаний и задайте им некоторые вопросы. Никогда не направляйте их или пытайтесь объяснить, как программное обеспечение работает. Это - задание UI (и правильно написанная документация).

Мы последовательно принимаем этот подход во всех проектах. Это является всегда захватывающим, чтобы наблюдать, что Пользователь имеет дело с программным обеспечением способом, который Вы никогда не рассматривали прежде.

, Почему дизайн UI настолько трудно? Хорошо обычно, потому что Разработчик и Пользователь никогда не встречаются.

5
ответ дан 23 November 2019 в 04:46
поделиться

Я знаю, что Microsoft довольно несовместима с их собственными инструкциями, но я нашел, что чтение их руководства по проектированию Windows действительно помогло мне. Я имею копию на своем веб-сайте здесь , просто прокручиваю немного вниз Руководство UX Vista. Это помогло мне с вещами, такими как цвета, интервал, разметки, и т.д.

4
ответ дан David Anderson 23 November 2019 в 04:46
поделиться

duffymo просто напомнил мне почему: Многие Программисты думают "*Design" == "Статья"

, Хороший дизайн UI абсолютно не профессионален. Это следует за твердыми принципами, которые могут быть сохранены с данными, если у Вас есть время для проведения исследования.

я думаю, что все программисты должны сделать, занимают время для изучения принципов. Я думаю, что это находится в нашем характере для применения лучшей практики каждый раз, когда мы можем, быть этим в коде или в расположении. Все, что мы должны сделать, делают нас знающий, что лучшие практики для этого аспекта нашего задания.

5
ответ дан nailitdown 23 November 2019 в 04:46
поделиться

Я полагаю, что основная проблема не имеет никакого отношения к различным талантам или наборам навыков. Основная проблема состоит в том, что как разработчик, Вы знаете слишком много о том, что делает приложение и как оно делает это, и Вы автоматически разрабатываете свой UI с точки зрения кого-то, у кого есть то знание.

принимая во внимание, что пользователь обычно начинает абсолютно ничего не знать о приложении и никогда не должен должен быть узнавать что-либо о его внутренних работах.

Это очень твердо, почти невозможно, для не использования знания, что Вы имеете - и вот почему UI не должен быть разработан кем-то, кто разрабатывает приложение позади него.

4
ответ дан Michael Borgwardt 23 November 2019 в 04:46
поделиться

"Разработка с обеих сторон экрана" представляет очень простую, но глубокую причину относительно того, почему программисты находят, что UI разрабатывает трудно: программисты обучены думать с точки зрения пограничных случаев, в то время как разработчики UI обучены думать с точки зрения общих падежей или использования.

Настолько идущий от одного мира до другого является, конечно, трудным, если значение по умолчанию traning в любом является полной противоположностью другого.

4
ответ дан MSN 23 November 2019 в 04:46
поделиться

Что я сделал для становления лучше в дизайне UI?
Обращают внимание на него!

Это похоже, как когда-нибудь время, Вы видите диаграмму на новостях или электронном знаке шины и Вы задаетесь вопросом, 'Как они получали те данные? Они делали это с сырыми данными sql, или они используют LINQ?' (или вставляют Ваше собственное общее любопытство фаната здесь).

необходимо начать делать это, но с визуальными элементами всех видов.

, Но точно так же, как изучение нового языка, если Вы не делаете действительно бросок сами в него, Вы никогда не будете изучать это.

Взятый от другой ответ я записал:

Учатся смотреть, действительно посмотрите в мире вокруг Вас. Почему я люблю тот UI, но ненавижу этого? Почему настолько трудно найти тарелки лапши в этом меню ресторана? Ничего себе, я знал то, что означал тот знак, прежде чем я даже считал слова. Почему это было? Каким образом та обложка книги выглядит настолько неправильной? Учитесь не торопиться для размышления о том, почему Вы реагируете способ, которым Вы делаете к визуальным элементам всех видов и затем применяете это к своей работе.

5
ответ дан Community 23 November 2019 в 04:46
поделиться

Дизайн UI труден

К вопросу:

почему так труден дизайн UI для большинства разработчиков?

Попытайтесь задать обратный вопрос:

почему программирует настолько трудный для большинства разработчиков UI?

Кодирование UI и разработка UI требуют различных навыков и другого мышления. Дизайн UI труден для большинства разработчиков, не некоторых разработчиков, как написание кода трудно для большинства разработчиков, не некоторых разработчиков.

Кодирование трудно. Дизайн труден также. Немного людей делают обоих хорошо. Хорошие разработчики UI редко пишут код. Они даже не могут знать, как, все же они - все еще хорошие разработчики. Итак, почему хорошие разработчики чувствуют себя ответственными за дизайн UI?

Знание больше о дизайне UI сделает Вас лучшим разработчиком, но это не означает, что необходимо быть ответственны за дизайн UI. Реверс верен для разработчиков: знание, как написать код, сделает их лучшими разработчиками, но это не означает, что они должны быть ответственны за кодирование UI.

Как поправиться при дизайне UI

Для разработчиков, желающих поправляться в UI, разрабатывают, у меня есть 3 основных совета:

  1. Распознайте дизайн как отдельный навык. Кодирование и дизайн является отдельным, но связанным. Дизайн UI не является подмножеством кодирования. Это требует другого мышления, базы знаний и группы навыка. Существуют люди там, которые фокусируются на дизайне UI.
  2. Узнайте о дизайне. По крайней мере, немного. Попытайтесь изучить несколько концепций проекта и методов из длинного списка ниже. Если Вы более амбициозны, прочитайте некоторые книги, посетите конференцию, посещайте урок, получите степень. Существует партия способов узнать о дизайне. Книга Joel Spolky по дизайну UI является хорошей краткой информацией для разработчиков, но существует намного больше к нему, и это - то, где разработчики входят в изображение.
  3. Работа с разработчиками. Хорошие разработчики, если Вы можете. Люди, которые делают эту работу, идут различными заголовками. Сегодня, наиболее распространенные заголовки являются Пользовательским Разработчиком Опыта (UXD), Информационным архитектором (IA), Разработчиком взаимодействия (ID) и Инженером Удобства использования. Они думают о дизайне так, как Вы думаете о коде. Можно изучить много от них и их от Вас. Работа с ними однако Вы можете. Найдите людей с этими навыками в Вашей компании. Возможно, необходимо нанять кого-то. Или перейдите к некоторым конференциям, посетите вебинары и проведите время в UXD/IA/ID мире.

Вот некоторые определенные вещи, которые можно изучить. Не пытайтесь изучить все. Если Вы знали, что все ниже Вас могло бы назвать себя разработчиком взаимодействия или информационным архитектором. Запустите с вещей около верхней части списка. Внимание на определенные понятия и навыки. Затем спуститесь и расширьтесь. Если Вы действительно любите этот материал, рассматриваете это как карьеру. Многие разработчики перемещаются в управления, но дизайн UX является другой опцией.

Почему дизайн UI труден

Хороший дизайн UI труден, потому что он включает 2 весьма различных навыков:

  • Глубокое понимание машины. Люди в этой группе волнуются о коде сначала, вторые люди. У них есть глубокое техническое знание и навык. Мы называем их разработчиками, программистами, инженерами, и т.д.
  • Глубокое понимание людей и дизайна: Люди в этой группе волнуются о людях сначала, второй код. У них есть глубокие знания того, как люди взаимодействуют с информацией, компьютерами и миром вокруг них. Мы называем их пользовательскими разработчиками опыта, информационными архитекторами, разработчиками взаимодействия, инженерами удобства использования, и т.д.

Это - существенное различие между этими 2 группами — между разработчиками и разработчиками:

  • Разработчики заставляют его работать. Они реализуют функциональность на Вашем TiVo, Вашем iPhone, Вашем любимом веб-сайте, и т.д. Они удостоверяются, что это на самом деле делает то, что это, как предполагается, делает. Их самый высокий приоритет заставляет его работать.
  • Разработчики занимаются людьми любовь это. Они выясняют, как взаимодействовать с ним, как это должно посмотреть, и как это должно чувствовать. Они разрабатывают опыт использования приложения, веб-сайта, устройства. Их самый высокий приоритет заставляет Вас влюбиться в то, что делают разработчики. Это - то, что предназначено по пользовательскому опыту, и это не то же как опыт бренда.

Кроме того, программирование и дизайн требует различных мышлений, не только другого знания и различных навыков. Хороший дизайн UI требует обоих мышлений, обеих баз знаний, обеих групп навыка. И требуются годы для освоения любого.

Разработчики должны ожидать находить, что UI разрабатывает трудно, так же, как разработчики UI должны ожидать находить написание кода трудно.

215
ответ дан 23 revs, 2 users 99% 23 November 2019 в 04:46
поделиться

Для этого есть много причин.

(1) Разработчик не видит вещей с точки зрения пользователя. Это обычный подозреваемый: отсутствие сочувствия. Но обычно это не так, потому что разработчики не такие чуждые, как их себе представляют.

(2) Другая, более распространенная причина заключается в том, что разработчик, который так близок к своим вещам, так долго оставался со своими вещами, не понимает, что его вещи могут быть не такими знакомыми (термин лучше, чем интуитивно понятный) другим людям.

(3) Еще одна причина - отсутствие у разработчика техники.

МОЕ БОЛЬШОЕ ЗАЯВЛЕНИЕ: прочтите любой пользовательский интерфейс, дизайн взаимодействия с человеком, книгу по прототипированию. например Проектирование очевидного: здравый смысл в дизайне веб-приложений, не заставляйте меня думать: здравый подход к веб-юзабилити, проектирование момента, что угодно.

Как они обсуждают потоки задач? Как они описывают точки принятия решения? То есть в любом случае существует как минимум 3 пути: успех, сбой / исключение, альтернатива.

Таким образом, из точки A можно перейти к A.1, A.2, A.3. Из точки A.1 вы можете добраться до A.1.1, A.1.2, A.1.3 и так далее.

Как они показывают такую ​​детализированную последовательность задач? Они этого не делают. Они просто замалчивают это.

Поскольку даже у экспертов по пользовательскому интерфейсу нет техники, у разработчиков нет шансов.Он думает, что это ясно в его голове. Но это непонятно даже на бумаге, не говоря уже о программной реализации.

Я должен использовать для этого свои собственные техники ручной работы.

8
ответ дан 23 November 2019 в 04:46
поделиться

Как бы вы это ни делали (и есть несколько замечательных моментов выше), это действительно помогло мне, когда я согласился с тем, что НЕТ ТАКОГО ИНТУИТИВНОГО НЕТ ....

Я слышу, как аргументы грохочут на горизонте .. Итак, позвольте мне немного объяснить.

Интуитивный: использование того, что кажется правильным или истинным, на основе бессознательного метода или чувства.

Если (как постулировал Карл Саган) вы соглашаетесь с тем, что не можете постичь вещи, которые абсолютно не похожи ни на что из того, с чем вы когда-либо сталкивались, то как вы могли «знать», как использовать что-то, если вы никогда не использовали ничего отдаленно похожего?

Подумайте об этом: дети пытаются открывать двери не потому, что они «знают», как работает дверная ручка, а потому, что они видели, как это делает кто-то другой ... часто они поворачивают ручку в неправильном направлении или слишком рано тянут ручку. Они должны УЗНАТЬ, как работает дверная ручка. Затем эти знания применяются в разных, но похожих случаях: открытие окна, открытие ящика, открытие почти всего большого с помощью большой ручки, похожей на ручку.

Даже простые вещи, которые кажутся нам интуитивными, не будут интуитивно понятны людям из других культур. Если кто-то протянул руку перед собой и взмахнул рукой вверх-вниз на запястье, при этом держа руку неподвижной… они отталкивают вас? Наверное, если вы не в Японии. Здесь этот сигнал рукой может означать «иди сюда». Так кто же прав? Оба, конечно, в своем собственном контексте. Но если вы путешествуете по обоим, вам нужно знать и то, и другое ... Дизайн пользовательского интерфейса.

Я пытаюсь найти то, что уже «знакомо» потенциальным пользователям моего проекта, а затем строю вокруг них пользовательский интерфейс: дизайн, ориентированный на пользователя.

Взгляните на iPhone от Apple. Даже если вы ненавидите это, вы должны уважать количество мыслей, которые были вложены в него. Это идеально? Конечно, нет. Со временем воспринимаемая «интуитивность» объекта может вырасти или даже полностью исчезнуть.

Например. Практически все знают, что черная полоса с двумя рядами отверстий сверху и снизу выглядит как пленка ... или не так ли?

Спросите своего среднего 9-10-летнего ребенка, что они думают об этом. Вы можете быть удивлены, сколько детей прямо сейчас будет трудно идентифицировать это как киноленту, даже если это что-то, что до сих пор используется для представления Голливуда или чего-либо, связанного с фильмом (фильмом). Большинство фильмов за последние 20 лет было снято в цифровом формате. И когда в последний раз кто-либо из нас держал в руках фильм ЛЮБОГО вида, фотографии или пленки?

Итак, для меня все сводится к следующему: знай свою аудиторию и постоянно исследуй, чтобы не отставать от тенденций и изменений. в вещах, которые являются «интуитивными», ориентируйтесь на своих основных пользователей и старайтесь не делать того, что наказывает неопытных в пользу продвинутых пользователей или замедляет продвинутых пользователей, чтобы держать новичков в руках.

В конечном счете, каждая программа потребует определенного обучения со стороны пользователя, чтобы использовать ее. Сколько обучения и для какого уровня пользователя - это часть решений, которые необходимо принять.

Некоторые вещи более или менее знакомы, исходя из прошлого опыта вашего целевого пользователя в качестве человека, пользователя компьютера, студента или кого-то еще.

Я просто стремлюсь к самой толстой части кривой и стараюсь привлечь как можно больше людей, но понимая, что я никогда не буду всем угодить ....

5
ответ дан 23 November 2019 в 04:46
поделиться

Сказать, что программы сосут при дизайне UI, означает упустить суть. Точка проблемы - то, что формальное обучение, которое получает большинство разработчиков, идет всестороннее с технологией. Человек - Компьютерное Взаимодействие не является простой темой. Это не что-то, что я могу "комбинация ума" Вам путем обеспечения простого одного оператора строки, который заставляет Вас понять, "что, о, пользователи будут использовать это приложение эффективнее, если я сделаю x вместо y".

Это вызвано тем, что существует одна часть дизайна UI, который Вы пропускаете. Человеческий мозг. Чтобы понять, как разработать UI, необходимо понять, как человеческий разум взаимодействует с оборудованием. Существует превосходный курс, который я взял в Миннесотском университете этой темы, преподававшей преподавателем Психологии. Это называют "Человеком - Взаимодействие Машины". Это описывает многие причины того, почему дизайн UI является так сложным.

, Так как Психология основана на Корреляциях и не Причинной связи, Вы никогда не можете доказывать, что метод дизайна UI будет всегда работать в любой данной ситуации. Можно коррелировать это, многие пользователи найдут конкретное обращение дизайна UI или эффективный, но Вы не можете доказать, что оно будет всегда делать вывод.

Кроме того, существует две части к дизайну UI, который многие люди, кажется, пропускают. Существует эстетическое обращение и функциональный рабочий процесс. Если Вы пойдете для 100%-го эстетического обращения, то верные люди будут, но Ваш продукт. Я высоко сомневаюсь, что эстетика будет когда-либо уменьшать пользовательское разочарование все же.

существует несколько хороших книг по этой теме и курсу для взятия (как Bill Buxton Пользовательские События Рисования эскизов , и Познание в Дикой природе Edwin Hutchins). Существуют программы специализации на Человеке - Компьютерное Взаимодействие во многих университетах.

полный ответ на этот вопрос, хотя находится в том, как людям преподают информатику. Это - вся базирующаяся математика, базирующаяся логика а не на основе пользовательского опыта. Для получения этого Вам нужны больше, чем универсальный 4-летний градус информатики (если Ваш 4-летний градус информатики не имел несовершеннолетнего в психологии и был подчеркнут в Человеке - Компьютерное Взаимодействие).

3
ответ дан 2 revs, 2 users 80% 23 November 2019 в 04:46
поделиться

Давайте изменим к лучшему Ваш вопрос -

, "ui разработчики", обреченные только разработать информационную архитектуру и уровни представления? Есть ли что-то, что они могут сделать для переквалификации их мозгов, чтобы быть более эффективными при разработке приятных и эффективных системных слоев?

Походит на них "ui, разработчики" должны были бы взять совершенно другую перспективу - они должны будут посмотреть с внутренней части поля за пределы; вместо того, чтобы заглянуть снаружи поля.

Alan Cooper "Обитатели Выполняет Убежище" , мнение - то, что мы не можем успешно взять обе перспективы - мы можем учиться носить одну шляпу хорошо, но мы не можем только переключить шляпы.

2
ответ дан igouy 23 November 2019 в 04:46
поделиться

Я думаю, потому что хороший UI не логичен. Хороший UI интуитивен.

Разработчики программного обеспечения обычно делают плохо на 'интуитивном'

2
ответ дан Gregor Brandt 23 November 2019 в 04:46
поделиться

Полезное структурирование должно активно рассмотреть то, что Вы делаете как разработка процесса коммуникации. В очень реальном смысле Ваш интерфейс является языком, который пользователь должен использовать для сообщения компьютера, что сделать. Это приводит к рассмотрению ряда вопросов:

  1. пользователь уже говорит на этом языке? Используя очень особенный интерфейс похож на передачу на языке, на котором Вы никогда не говорили прежде. Таким образом, если Ваш интерфейс должен быть особенным вообще, он имел, лучше всего начинают себя с самого простого из условий и немногих отвлекающих факторов. С другой стороны, если Ваш интерфейс будет использовать идиомы, к которым приучен пользователь, то они завоюют доверие от запуска.
  2. враг коммуникации является шумом. Слуховой шум вмешивается в разговорную коммуникацию; визуальный шум вмешивается в видеосвязь. Чем более шумовой можно сократить из интерфейса, тем более легкое общение с это будет.
  3. Как в человеческом разговоре, это часто не, что Вы говорите, это - как Вы говорите это. Путем большая часть программного обеспечения связывается, грубо в известной степени, который перфорировал бы его в поверхность, если бы это был человек. Как Вы чувствовали бы, задали ли Вы кому-то вопрос, и они сидели там и уставились на Вас в течение нескольких минут, отказавшись отвечать каким-либо другим способом, перед ответом? Много интерфейсных элементов, как индикаторы выполнения и автоматический выбор фокуса, имеют фундаментальную функцию вежливости. Спросите себя, как можно сделать день пользователя немного более приятным.

Действительно, несколько трудно определить, какие программисты думают об интерфейсном взаимодействии, как являющемся, другой , чем процесс коммуникации, но возможно проблема состоит в том, что это не получает мысль как являющийся ничем вообще.

2
ответ дан chaos 23 November 2019 в 04:46
поделиться

Уже существует много o хороших комментариев, таким образом, я не уверен, что существует очень, я могу добавить. Но все еще...

  • , Почему разработчик ожидал бы мочь разработать хороший UI?
  • , Сколько обучение, он имел в том поле?
  • , Сколько книг он читал?
  • , Сколько вещи, он разработал сколько лет?
  • Сделал у него была возможность видеть реакцию, он - пользователи?

Мы не ожидаем что случайный "Joe водопроводчик" мочь написать хороший код. Итак, почему мы ожидали бы, что случайный "Joe программист" разработает хороший UI?

Сочувствие помогает. Разделение дизайна UI и программирования помогает. Тестирование удобства пользования помогает.

, Но дизайн UI ремесло, которое должно быть изучено и осуществлено, как любой другой.

2
ответ дан Mihai Nita 23 November 2019 в 04:46
поделиться

Разработчики не (обязательно) хороши в дизайне UI по той же причине, они не (обязательно) хороши в вязании; это твердо, это берет практику, и не повреждает сделать, чтобы кто-то показал Вам как во-первых.

Большинство разработчиков (меня включенный) начало "разрабатывать" UIs, потому что это была необходимая часть записи программного обеспечения. Пока разработчик не вставит усилие стать хорошим в нем, он или она не будет.

2
ответ дан MattBelanger 23 November 2019 в 04:46
поделиться

Для улучшения просто озираются на существующих сайтах. В дополнение к книгам, уже предложенным, Вы хотели бы взглянуть на превосходную книгу Robin Williams "Книга Дизайна Неразработчиков" ( санированная ссылка Amazon )

, Взглянули на то, что возможно в визуальном проектировании путем взгляда на различные представления, законченные в Zen-Garden также.

дизайн UI является определенно искусством, хотя, как указатели в C, некоторые люди получают его, и некоторые люди не делают.

, Но по крайней мере у нас может быть хихиканье при их попытках . BTW Спасибо OK/отмена для забавного комика и благодарна за то, что Joel помещает его в Вашу книгу "Лучшее программное обеспечение, Пишущий I" ( санированная ссылка Amazon ).

2
ответ дан Rob Wells 23 November 2019 в 04:46
поделиться

Пользовательский интерфейс не что-то, что может быть применено после факта, как тонкий слой краски. Это - что-то, что должно быть там в запуске, и на основе реального исследования. Существуют тонны исследования Удобства использования, доступного, конечно. Это не должно только быть там в запуске, это должно сформировать ядро самой причины, Вы делаете программное обеспечение во-первых: существует некоторый разрыв в мире там, некоторая проблема, и это должно быть сделано более применимым и более эффективным.

программное обеспечение не там ради самого себя. Причина части программного обеспечения для существования ДЛЯ ЛЮДЕЙ. Это абсолютно смехотворно, чтобы даже попытаться придумать идею для новой части программного обеспечения, не понимая, почему любому был бы нужен он. Все же это происходит все время.

, Прежде чем одна строка кода записана, необходимо пройти бумажные версии интерфейса и протестировать его на настоящих людях. Это довольно странно и глупо, это работает лучше всего с детьми и кем-то интересное действие как "компьютер".

интерфейс должен использовать в своих интересах наши естественные познавательные средства. Как пещерный человек использовал бы Вашу программу? Например, мы развились, чтобы быть действительно хорошими в отслеживании движущихся объектов. Вот почему интерфейсы, которые используют моделирования физики, как iPhone, работают лучше, чем интерфейсы, где изменения происходят мгновенно.

Мы способны к определенным видам абстракции, но не другим. Как программисты, мы обучены сделать умственную гимнастику и перевороты назад для понимания некоторых самых странных абстракций. Например, мы понимаем, что последовательность тайного текста может представить и быть переведена в шаблон электромагнитного состояния на металлическом диске, который при обнаружении тщательно разработанным устройством приводит к последовательности невидимых событий, которые происходят в lightspeed на электронной схеме, и эти события могут быть предписаны произвести полезный результат. Это - невероятно неестественная вещь должным быть понять. Поймите, что, в то время как это имеет совершенно рациональное объяснение нам к внешнему миру, похоже, что мы пишем непостижимые заклинания для вызова невидимых разумных духов для выполнения наших указаний.

виды абстракций, которые понимают нормальные люди, являются вещами как карты, схемы и символы. Остерегайтесь символов, потому что символы являются очень хрупким человеческим понятием, которые прилагают сознательные умственные усилия для декодирования, пока символ не изучен.

прием с символами - то, что должны быть ясные отношения между символом и вещью, которую это представляет. Вещью это представляет любого, должно быть существительное, в этом случае символ должен ОЧЕНЬ походить на вещь, которую это представляет. Если символ представляет более абстрактное понятие, которое должно быть объяснено ЗАРАНЕЕ. Посмотрите непостижимые unlabled значки в MSWord, или панель инструментов фотошопа и абстрактные понятия, которые они представляют. Нужно ИЗУЧИТЬ, что значок инструмента обрезки в фотошопе означает ИНСТРУМЕНТ ОБРЕЗКИ. нужно подразумевать, что ОБРЕЗАЕТ даже средства. Это предпосылки к корректному использованию того программного обеспечения. Который поднимает важный момент, остерегайтесь ПРИНЯТОГО знания.

Мы только получаем способность понять карты вокруг возраста 4. Я думаю, что читал где-нибудь однажды тот, шимпанзе получают способность понять карты вокруг возраста 6 или 7.

причина, что guis были так успешны для начала, состоит в том, что они изменили среду главным образом текстовых интерфейсов к компьютерам к чему-то, что отобразило компьютерные понятия на что-то, что напомнило физическое место. Где сбой guis с точки зрения удобства использования, то, где они прекращают напоминать что-то, что Вы видели бы в реальной жизни. Существуют невидимые, непредсказуемые, непостижимые вещи, которые происходят в компьютере, который пустой никакое подобие чему-либо Вы когда-либо видели бы в материальном мире. Часть этого необходима, так как не было бы никакого смысла в просто делании реальностью средства моделирования - идея состоит в том, чтобы сохранить работу, таким образом, должно быть немного волшебства. Но то волшебство должно иметь смысл и быть основано в абстракции, что люди хорошо адаптированы к пониманию. Это - когда наши абстракции начинают становиться глубокими, и разделенными на уровни и не соответствовавшими с задачей под рукой, что вещи ломаются. Другими словами, интерфейс не функционирует как хорошую карту для базового программного обеспечения.

существует много книг. Два я читал, и может поэтому reccomend, быть "Дизайном Повседневных Вещей" donald нормандцем, и "Интерфейсом пользователя" Jef Raskin.

я также reccomend курс в психологии. "Дизайн Каждого дня Вещи" говорит об этом немного. Много интерфейсов ломается из-за "народного понимания разработчика" психологии. Это подобно "народной физике". Объект в движении остается в движении, не имеет никакого смысла большинству людей. "Необходимо продолжать продвигать это сохранять его в движении!" думает новичок физики. Пользователь, тестирующий, не имеет смысла большинству разработчиков. "Можно просто спросить пользователей, что они хотят, и это должно быть достаточно хорошо!" думает новичок психологии.

я reccomend Обнаружение Психологии, документального сериала PBS, размещается Philip Zimbardo. Сбой этого, попытайтесь найти хороший учебник по физике. Дорогой вид. Не чтиво сам помогает дерьму, которое Вы находите в Границах, но толстом материале в твердом переплете, который можно только найти в университетской библиотеке. Это - necesesary основа. Можно сделать хороший дизайн без него, но у Вас только будет интуитивное понимание того, что продолжается. Чтение некоторых хороших книг даст Вам хорошую перспективу.

2
ответ дан Breton 23 November 2019 в 04:46
поделиться

При чтении книги, "Почему программное обеспечение сосет", Вы видели бы ответ Platt, который является простым:

  1. управление Разработчиков перед другом удобным для пользователя
  2. предварительный друг Обычных людей, удобный для пользователя по управлению

, Но другой другой ответ на Ваш вопрос, был бы, "почему так трудна стоматология для некоторых разработчиков?" - дизайн UI лучше всего сделан разработчиком UI.

http://dotmad.net/blog/2007/11/david-platt-on-why-software-sucks/

2
ответ дан dotmad 23 November 2019 в 04:46
поделиться
Другие вопросы по тегам:

Похожие вопросы: