То, что некоторые хорошие инструкции по удобству использования являются средним разработчиком, должно следовать? [закрытый]
У меня есть предложение по указанной выше проблеме. Нет необходимости в дополнительном списке или дополнительном времени. Пожалуйста, найдите пример, который будет делать одни и те же вещи, но по-другому.
//"list" is ArrayList<Object>
//"state" is some boolean variable, which when set to true, Object will be removed from the list
int index = 0;
while(index < list.size()) {
Object r = list.get(index);
if( state ) {
list.remove(index);
index = 0;
continue;
}
index += 1;
}
Это позволит избежать исключения параллелизма.
17 ответов
Предоставьте сочетания клавиш для опытных пользователей (даже если это так же просто, как «нажать Enter для поиска»)
Не выводите слишком много на экран сразу.
Если вы откроете окно сообщения, ваши пользователи, как правило, никогда его не прочитают.
Предлагаю прочитать эти посты в блоге от создателей Enso .
Конечно, они повторяют руководства / идеи / советы из книг, таких как
Дизайн повседневных вещей и О лице , но, тем не менее, посты содержат довольно несколько идей и (IMO) они хорошо читаются.
Вот несколько простых правил:
- Чем меньше кликов, тем лучше.
- Часто используемые функции должно быть легче найти.
- Возможности «продвинутых» пользователей найти сложнее, чем приведенные выше.
Подумайте о том, сколько нажатий мыши / клавиатуры требуется пользователю, чтобы что-то получить.
PS - пожалуйста, не говорите об этом Microsoft Office 2008; бедные маленькие парни будут плакать сегодня ночью! :)
Единственный самый важный совет, который я дал бы кому-то, должен работать над UI сначала. Перо и бумага и так далее. Тем путем Вы подсознательно не свяжете кнопки с функциями, поля ввода к переменным, и т.д.
, лучший UI мог бы быть болью для кодирования, и если код бэкенда будет главным образом записан, он будет саботировать взгляды.
, Кроме которого, я указал бы на Инструкции по Интерфейсу пользователя Apple . Конечно, если Ваша платформа не является OS X, возьмите OS X разделов с большим количеством соли. Какие работы в OS X не мог бы работать над Windows. Необходимо охватить идиомы платформы.
OS X материалов в стороне, тот документ имеет некоторые довольно хорошие начальные точки на основных принципах.
Избегайте режимы . Печально пользователю, когда введенные работы иногда, но не другие, или делает разные вещи в разное время.
- не заставляют вещи работать по-другому, чем Ваши пользователи ожидают (т.е. повреждают "заднюю" кнопку, когда использование Ajax в веб-формах
- Следует за принципалом K.I.S.S
Действительно, любые правила, которые кто-то отправляет, будут изменением на теме: не Заставляют Ваших Пользователей Думать
, "не Заставляют Меня Думать", был уже отправлен, см. также Дизайн Повседневных Вещей и Разработка с веб-стандартами , которые являются также большими для легкого чтения удобства использования.
Просто две вещи, на самом деле:
- «Пользовательский интерфейс хорошо спроектирован, когда программа ведет себя именно так, как думал пользователь», - цитирует Джоэла Спольски Дизайн пользовательского интерфейса для программистов
- Поставьте свои проекты перед пользователем. Реальный конечный пользователь лучше, но для облегченной, быстрой обратной связи вы не можете превзойти тестирование юзабилити в коридоре, то есть захватить коллегу.
Если вы помните совет Джоэла и будете получать отзывы о том, что вы делаете , и будете действовать в соответствии с ним , то есть повторяться, вы не ошибетесь слишком далеко. И я бы повторил рекомендацию для Стива Круга «Не заставляй меня думать» - это, пожалуй, лучшая книга, связанная с работой, которую я когда-либо читал, без исключения, и она так же применима к настольному программному обеспечению, как и к веб-сайтам. 117]
Надеюсь, это поможет.
Читайте , не Заставляют Меня Думать Steve Krug . Это - большая начальная точка и легкое короткое чтение.
РЕДАКТИРОВАНИЕ: Это главным образом для удобства пользования веб-страницами, хотя, но это все еще было бы хорошее чтение даже при выполнении толстых клиентов.
Думайте о пользователях, которые будут использовать Ваше приложение. Почему они используют его и в который контекст?
- большинство будет про пользователями, которые знают домен, в котором используется приложение, и используйте приложение много? Тогда не бойтесь добавления большого количества данных на экраны, пока оно расположило логически для пользователей (обычно, который не является в алфавитном порядке:-). Думайте торговые экраны для брокеров запаса или кабин самолета.
- пользователи случайные пользователи? Сохраните его простым. Избегайте контекстных переключений (сохраните все/целый возможными из необходимых данных для задачи на экране каждый раз). Не повреждайте ожидания того, как обычно работают gui виджеты. Дизайн для отказов.
- Что-либо промежуточное? Позвольте пользователям расти в UI. Использование дорожки, таким образом, можно позже определить, где пользователи, кажется, проводят большую часть времени, таким образом, можно улучшить наиболее используемые области приложения.
- Тест Ваше приложение на друзьях и коллегах (тест коридора), чтобы видеть, в состоянии ли они использовать его эффективно.
Это - запуск.
Какая информация нужна вашему пользователю, выводите ее на экран и ничего больше. Если вы не можете определить, что нужно пользователю - найдите другого пользователя.
Помните, что ваше приложение будет одним из многих, с которыми пользователю придется иметь дело. Не делайте вещей только для того, чтобы отличаться от других или просто клевать. Не придумывайте необычную графику, поведение, терминологию или взаимодействия. Используйте стандартные элементы управления ОС, соглашения, служебные программы и поведение.
Разрешите вашему приложению взаимодействовать с другими приложениями; позволять вырезать и вставлять данные, сохранять данные в форматах, которые могут быть прочитаны другими приложениями, и разрешать импорт данных из других приложений вместо использования пользовательского интерфейса.
Если вы создаете настольное приложение, не пытайтесь захватить компьютер пользователя . Не трогайте папку «Документы», панель задач и настройки приложения. Не меняйте ничего, что уже установлено на компьютере. Разрешить взаимодействие с помощью сценариев или командной строки.
Если вы создаете веб-приложение, не пытайтесь захватить контроль над браузером. Не пытайтесь разрушить стандартные строки меню, историю, макет или шрифты. Разрешить пользователю изменять страницу с помощью Javascript.
В дополнение к другим рекомендациям я бы порекомендовал Designing Interfaces от Jenifer Tidwell как хороший способ познакомиться с соглашениями пользовательского интерфейса.
Кроме того, Заключенные управляют приютом Алан Купер отлично подходит для понимания того, как подходить к дизайну взаимодействия.
- Простое лучше, чем сложное
- Сложное лучше, чем сложное (исключите «вложенные если»)
- Интуитивно (хорошо элементы не требуют объяснения)
- Следуйте соглашению (например, подчеркнутый означает ссылку, красный означает ошибку, табуляция переходит к следующему полю и т. д.)
- Используйте семантику для применения логики (сначала читается заголовок, абзацы следующий)
- пробелы важны
Хорошим продолжением «Не заставляйте меня думать» является Роберт Хукман Создание очевидного . Он больше ориентирован на веб-приложения, чем на веб-сайты, как у Круга.
(1) Обычные действия должны требовать как можно меньше усилий и быть очевидными; с другой стороны, действия, которые нужны редко, могут требовать много шагов и могут быть скрыты за меню и диалогами. Чтобы иметь такую возможность, вы всегда должны описывать, что пользователь захочет делать с приложением, перечисляя сценарии использования.
(2) Пользовательский интерфейс должен быть самодокументирующимся. Руководство должно быть интегрировано в диалоги и меню приложения, так как пользователи не читают отдельные руководства. Например, сочетание клавиш должно отображаться в пункте меню, представляющем действие, с которым оно связано.