Опубликован: 06.05.2014 | Доступ: свободный | Студентов: 2619 / 601 | Длительность: 10:33:00
Лекция 2:

Особенности интерфейсов для смартфонов. Принципы юзабилити

Поведение окон и определение компоновки

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

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

Лишние комнаты

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

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

Диалоговое окно – это еще одна комната; не ходите в комнату без веской причины.

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

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

Важные окна

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

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

Инструменты программы рисования следует располагать у границы холста и делать доступными в одно действие. Пользователя не следует отправлять за ними в меню или диалоговое окно ( рис. 3.9).

Главный экран приложения Glow Drow не содержит ничего лишнего.

Рис. 3.9. Главный экран приложения Glow Drow не содержит ничего лишнего.

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

Замусоривание окнами

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

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

Проектирование для различных потребностей

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

Командные векторы, рабочие наборы и персонажи

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

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

Масштаб изображения можно изменять разными способами. На экране есть специальные кнопки; в то же время опытные пользователи сенсорных экранов ими практически не пользуются, предпочитая одновременное сведение/разведение двух пальцев (один из жестов технологии мультитач).

Рис. 3.10. Масштаб изображения можно изменять разными способами. На экране есть специальные кнопки; в то же время опытные пользователи сенсорных экранов ими практически не пользуются, предпочитая одновременное сведение/разведение двух пальцев (один из жестов технологии мультитач).

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

Поскольку в памяти каждого пользователя невольно откладываются часто используемые команды, многие запоминают некоторое подмножество команд, называемое рабочим набором . У каждого пользователя свой рабочий набор, хотя весьма вероятно, что он значительно пересекается с рабочими наборами других пользователей. Строго говоря, не существует стандартного рабочего набора, покрывающего потребности всех пользователей, исследование и моделирование пользователей и способов использования продукта позволяют получить минимальное подмножество команд, необходимых большинству. Такой минимальный рабочий набор можно определить методами целеориентированного проектирования – посредством сценариев, раскрывающих функциональные потребности персонажей.

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

Существует исключение из правила множественных векторов. Опасные команды (такие как Стереть все) не должны иметь легко доступных множественных командных векторов. Их следует защищать посредством меню и диалоговых окон.