Blob Blame History Raw
<?xml version="1.0" encoding="utf-8"?>
<page xmlns="http://projectmallard.org/1.0/" type="topic" id="design-principles" xml:lang="ru">

  <info>
    <credit type="author">
      <name>Алан Дэй (Allan Day)</name>
      <email>aday@gnome.org</email>
    </credit>
    <include xmlns="http://www.w3.org/2001/XInclude" href="legal.xml"/>
    <desc>Основные рекомендации и советы по проектированию.</desc>
  </info>

<title>Принципы проектирования</title>

<p>Описываемые ниже принципы проектирования утверждают ряд основных правил, следование которым позволяет обеспечить высокий уровень удобства использования ваших приложений.</p>

<section id="focus">
<title>Сосредоточьтесь на главном</title>

<p>Одним из главнейших факторов успешного проекта является чёткое определение решаемой задачи. Очертите круг будущих непротиворечивых функций, не допускайте «расползания» задачи, т. е. не включайте новые элементы в уже принятый план. Приложение, которое пытается решить слишком много задач, в конечном итоге становится слишком сложным и непонятным для пользователей.</p>

<p>Запомните: лучшие приложения — это приложения, которые предлагают качественное решение для определённой области задач.</p>

</section>

<section id="complexity">
<title>Интерфейс должен быть простым</title>

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

<p>При добавлении нового элемента управления или текста подумайте, действительно ли нужно включать его в приложение.</p>

</section>

<section id="progressive-disclosure">
<title>Скрывайте неиспользуемые элементы управления</title>

<p>Скрывайте элементы управления, которые не применяются в данный момент времени или в текущем контексте использования. Сокрытие неиспользуемых элементов упрощает работу с приложением, в противном случае они будут мешать пользователю.</p>

<p>Существует ряд различных подходов для сокрытия элементов управления, начиная от использования различных режимов просмотра и заканчивая временными или «плавающими» элементами управления, которые появляются или исчезают, когда пользователь выбирает что-то в интерфейсе.</p>

</section>

<section id="work">
<title>Избавьте пользователя от излишней работы</title>

<p>Сложные в использовании приложения раздражают пользователей. Постарайтесь сделать так, чтобы ваше приложение работало за пользователя, а не наоборот. Каждый раз, когда приложению требуется ввод информации от пользователя (неважно, идёт ли речь о вводе текстовой информации или об использовании каких-либо элементов управления), подумайте, нельзя ли выполнить эту работу за пользователя.</p>

<p>Постарайтесь свести к минимуму необходимость в использовании экранов настройки. Сделайте так, чтобы пользователь мог легко вернуться к своей работе.</p>

</section>

<section id="hierarchy">
<title>Элементы интерфейса должны быть последовательными</title>

<p>Пользователи привыкли «считывать» интерфейс слева направо и сверху вниз. Таким образом, элементы, которые по порядку «считывания» предшествуют другим элементам, должны должны располагаться левее и/или выше этих элементов.</p>

<p>Располагайте наиболее важные элементы управления в левой верхней части окна. Если элементы управления оказывают воздействие на другие элементы, то они должны располагаться рядом друг с другом. Подробнее см. <link xref="visual-layout">руководство по визуальному расположению</link>.</p>

</section>

<section id="content">
<title>Главное — это содержимое</title>

<p>Приложения обычно предоставляют некое содержимое. Это может быть изображение, текст, сообщение или произвольные данные. Иными словами, содержимое — это информация, которая интересует пользователя, поэтому обилие управляющих элементов будет отвлекать внимание пользователя от содержимого.</p>

<p>Содержимое должно занимать максимально возможную область в пользовательском интерфейсе. Сократите количество управляющих элементов, не захламляйте интерфейс второстепенной информацией.</p>

</section>

<section id="errors">
<title>Прогнозируйте ошибки</title>

<p>Людям свойственно ошибаться. Прогнозирование ошибок позволяет предотвратить разрушительные последствия допущенных ошибок. Приложения, создаваемые с прогнозированием ошибок, удобнее и приятнее в использовании. Первая линия обороны — проектирование приложений таким образом, чтобы пользователь вообще не смог допустить ошибку. Вторая линия — максимальное упрощение исправления допущенной пользователем ошибки.</p>

<p>Автоматически исправляйте потенциально некорректные введённые данные. Всегда оставляйте возможность отменить деструктивные действия.</p>

</section>

<section id="interruptions">
<title>Не отвлекайте пользователя</title>

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

<p>Не злоупотребляйте <link xref="notifications">уведомлениями</link>. Избегайте всплывающих диалоговых окон с бесполезной для пользователя информацией, а также отвлекающих механизмов обратной связи, таких как диалоги сообщений.</p>

</section>

<section id="search">
<title>Используйте быстрый поиск</title>

<p><link xref="search">Поиск</link> является мощным средством, с помощью которого можно быстро найти нужную информацию. Если пользователь работает с большим количеством информации (она может быть представлена в виде списков, таблиц и т. п.), предоставьте функцию поиска. Поиск должен работать максимально быстро.</p>

<p>GNOME 3 предоставляет свои собственные средства поиска. Интегрировав поиск в приложении с GNOME 3, пользователи смогут быстро получать доступ к содержимому вашего приложения.</p>

</section>

<section id="options">
<title>Не перестарайтесь с параметрами настройки</title>

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

</section>

<section id="name-and-icon">
<title>Название приложения должно быть осмысленным</title>

<p><link xref="application-basics#application-names">Название</link> приложения и его <link xref="icons-and-artwork#application-icons">значок</link> являются важными выразительными средствами. Выбирая их исходите из того, что они должны быть как-то связаны с функциями приложения. Убедитесь, что по названию приложения пользователи могут понять, что делает ваше приложение. Значок является визитной карточкой приложения, поэтому постарайтесь сделать его привлекательным и запоминающимся.</p>

</section>

<section id="emotion">
<title>Можно немного пошутить</title>

<p>Немного юмора не помешает. При разумном применении это понравится пользователям. Но не перегибайте палку: лучше всего использовать подобную технику в приложении в нескольких местах, не стоит щедро сдабривать пользовательский интерфейс шутками и прочими вольностями.</p>

<p>Постарайтесь сделать так, чтобы ваше приложение располагало к себе пользователей, когда оно запускается впервые. Ещё один эффективный приём — если в приложении произошла аварийная ситуация, обставьте её с юмором.</p>

</section>

</page>