Является ли хорошей идеей иметь одну и ту же функцию в двух разных меню?

Question

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

Простой пример, допустим, у меня есть следующие меню:

• Файл
• отложенные ордера
• Принятые заказы
• Инструменты
• Помощь

У меня есть функция поиска, и одно и то же окно поиска работает как для отложенных, так и для принятых заказов (это просто комбо «статус заказа», которое вы можете изменить)

Куда относится эта функция поиска?

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

• Дублирование пункта меню в отложенном и принятом порядке кажется мне неправильным .

Что бы вы сделали? (И давайте представим, что мы не можем объединить меню двух заказов в одно меню)

Answer 1

Я думаю, что проблема, с которой вы столкнулись, заключается в том, что вы думаете как программист. (дублирование кода плохое). Я не осуждаю тебя за это, я делаю то же самое. Несколько путей к одному экрану или несколько способов управления одним и тем же процессом могут быть чрезвычайно полезными. Я предполагаю, что более чем один человек собирается использовать вашу программу, и у каждого, вероятно, есть немного разные рабочие функции. По сути, они имеют разные потребности в приложении и будут подходить к нему по-разному. Если вы придерживаетесь того, что ко всем элементам есть один доступ, некоторые найдут приложение полезным, а другие - нет. Конечно, все люди могут научиться выполнять задачу определенным образом, но для некоторых пользователей это не имеет смысла. Это не интуитивно (читай знакомо), как они используются для обработки информации, что означает, что приложение в конечном итоге будет менее полезным для них. Когда люди находят процесс (программу и т. Д.) Разочаровывающим, они не принимают его. Они находят причины, по которым процесс нужно будет изменить или отменить.

Отличным примером множественных подходов к проблеме является Adobe Photoshop. Обычно есть как минимум 2 разных способа доступа к функции. Большинство пользователей знают только об одном, потому что это все, что их волнует, но большинству пользователей действительно удобно использовать один, потому что это имеет для них наибольшее значение. С небольшой дополнительной работой Adobe одержала огромную победу, потому что все больше людей находят свой продукт интуитивно понятным.

Answer 2

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

Например, в вашем примере показана строка меню, организованная по классу или атрибуту объекта, над которым действуют команды. В целом, строка меню должна быть организована по категории действия, а не по типу объекта. Например, у вас может быть меню «Поиск» для таких команд, как «Поиск» и другие средства отображения заказов, и меню «Изменить» для обработки заказов (например, обновление, принятие, пересылка). Оба меню имеют пункты меню, которые применяются к обоим типам объектов, хотя некоторые команды могут применяться только к одному.

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

Answer 3

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

В приведенном выше примере поиска вы увидите, что приложения используют два подхода:

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

Если вы повторите приведенный выше выбор для ряда факторов, вы увидите гораздо более продвинутый (он же «сложный») интерфейс поиска для номера один и намного более простой (он же «ограничительный») интерфейс поиска для номера два.

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

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

В приведенном выше примере поиска, если пользователь уже перешел в меню «Ожидание заказов», вероятность того, что он захочет запустить поиск «Принятые заказы», ​​очень мала и ему придется сделать этот выбор, или перейти в другое место для выполнения поиск, будет дополнительным решением или действием, которое они должны будут предпринять. Основной принцип: если ваш пользователь уже принял решение, используйте его; не заставляйте их говорить вам снова.

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

Answer 4

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

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

Answer 5

Просто поместите его в оба меню и откройте окно поиска, предварительно настроенное для типа заказа, из меню которого оно было запущено. Назовите их соответствующим образом и вуаля, на самом деле это два разных действия - даже если они используют один и тот же код / ​​компонент.

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

Answer 6

... вы, возможно, уже знаете это, но это хорошее место для использования шаблона command \ action IMHO.

Итак, чтобы ответить на ваш вопрос: ИМО, да, все в порядке :) Эта ситуация определенно оправдана.

Answer 7

Я бы попытался выполнить поиск в меню «Принятые заказы» и «Ожидание заказов» Тем не менее, пользовательское тестирование покажет, если это хорошая идея или нет. Но это также зависит от вашей пользовательской базы.

Вы проводите пользовательское тестирование, верно?