Практические методы проектирования пользовательских интерфейсов для мобильных Интернет-устройств (MID)

Практические методы проектирования пользовательских интерфейсов для мобильных Интернет-устройств (MID)

23.11.2007

Источник: Intel Software Network

Краткий обзор

Мобильные Интернет-устройства (MID - Mobile Internet Device) представляют собой новейшую разработку в семействе персональных компьютеров. Они потребляют мало энергии и имеют все преимущества ПК. При разработке функций и приложений MID необходимо учитывать множество аспектов, чтобы пользователь мог с удовольствием работать с интерфейсом MID. В данной статье дается обзор методов проектирования пользовательских интерфейсов для MID. Пользовательский интерфейс Hildon является задачно-ориентированным, так что требует особого подхода. В статье также  предлагаются практические методы проектирования пользовательского интерфейса Hildon.

1. Введение в MID

Мобильные Интернет-устройства (MID - Mobile Internet Device) представляют собой новейшую разработку в семействе персональных компьютеров. Они потребляют мало энергии и имеют все преимущества ПК. Мобильные Интернет-устройства – это устройства с малым форм-фактором, что дает возможность носить их с собой повсюду. При этом ультрамобильные устройства могут оставаться подключенными 24 часа в день, 7 дней в неделю. Intel активно разрабатывает и поставляет технологии, отвечающие потребностям пользователей MID. Один из основных вкладов, внесенных Intel в стремительное развитие устройств MID, - реализация программного обеспечения, связанного с драйвером графического адаптера Intel® Graphics Media Accelerator 915GM. MID имеют жидкокристаллический, относительно маленький (4.5” – 6”), с высоким разрешением, сенсорный экран и уменьшенную клавиатуру. Чтобы пользовательские ощущения были адекватны используемому устройству, контент для MID должен быть легко читаем, а пользовательский интерфейс легко управляться «одним пальцем». Это означает, что пользовательский интерфейс ОС и приложения должны иметь возможность развернутой настройки пользователем.

2. Обзор|Midinux

Linux – ОС с открытым исходным кодом, которая имеет большие возможности по настройке, от системного уровня (быстрая загрузка, быстрый выход из режима ожидания) до уровня приложений (стиль и темы пользовательского интерфейса). Midinux – первая ОС на базе Linux, которая полностью поддерживает платформу Intel 2007 MID. В ней имеется среда мобильных приложений на базе GTK, оптимизированная для размера и разрешения экранов MID. На рис.1 показана схема среды приложений MID.

Рис.1. Схема среды приложений MID
2.1 Обзор Hildon

>Пользовательский интерфейс Hildon в целом основан на компонентах с открытым исходным кодом, также как и Maemo. Hildon основан на GTK+, инструментарии, используемом в настольных ПК Gnome и немного адаптированном для лучшей работы с мобильными устройствами. Первый продукт с пользовательским интерфейсом в стиле Hildon - Nokia 770 Internet Tablet. Этот интерфейс во многом ориентирован на операции с сенсорным экраном, то есть пользователь должен взаимодействовать с устройством, используя перо или палец. Несмотря на то что на нем имеются несколько обязательных аппаратных кнопок, пользователи обычно работают с устройством при помощи сенсорного экрана. Hildon поддерживает многозадачность, то есть несколько приложений могут быть запущены одновременно, и пользователь может переключаться между ними. В интерфейсе Hildon четыре основных компонента: навигатор задач, область заголовка, область индикатора состояния и область приложения. Навигатор задач – это общий экранный элемент, который находится наверху экрана. Навигатор задач используется для запуска приложений и переключения между ними. Область заголовка  содержит заголовок приложения, который открывает специфичное для этого приложения меню. С правой стороны этой области находятся кнопки минимизации и закрытия приложения. Область индикатора состояния содержит значки, которые описывают состояние и поведение системы. Здесь находятся апплеты строки состояния. Область приложений занимают приложения, работающие в обычном режиме. В полноэкранном режиме все остальные области исчезают, и эта область приложений расширяется на весь экран. На рис.2 показан общий вид пользовательского интерфейса приложения MID.

Рис. 2. Вид пользовательского интерфейса приложения MID

3. Проблемы проектирования пользовательских интерфейсов MID и практические методы работы

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

3.1 Фактор размера экрана

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

3.1.1 Размеры текста и значков

Проблема: в интерфейсах приложений, которые переносятся на MID, текст и значки могут быть сжаты до такой степени, что они становятся трудно читаемыми. Текст, размер которого выглядит вполне логичным на 15-дюймовом экране, может стать слишком маленьким при его урезании до масштабов экрана пять на семь дюймов, обычного для MID. Кроме реального размера шрифта текста, слишком маленькими могут стать чат и другие текстовые окна. Уменьшение размера шрифта для приспособления к меньшему размеру окна может сделать текст трудно читаемым.

(a)

(b)
Рис 3. Подходящий размер шрифта для читаемого (a) и не читаемого текста без адекватного масштабирования (b).

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

3.1.2 Использование кнопок и других нажимаемых элементов

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

Рис. 4.  Нажатие кнопок. На 20-дюймовом ПК-мониторе (слева) пользователь может легко найти и выбрать кость домино, используя обычный курсор-стрелку. Когда изображения костей масштабируются до 5-дюймового экрана UMPC (справа), пользователю становится очень трудно выбрать каждую из них и даже определить, сколько точек на каждой кости.

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

3.1.3 Размер окна

Проблема: Если окна приложения имеют фиксированный размер, а не изменяемый до полного экрана MID, некоторые их участки могут вдруг оказаться невидимы и, в конечном счете, недоступны. Эта ситуация осложняется необходимостью использовать свойственные широкому экрану MID разрешения 800x480 и 1024x600, поскольку эти форматные соотношения не совпадают со стандартной пропорцией ПК - 4:3.

Рис. 5. Видимость окна. На стандартном ПК (слева) пользователь может видеть все игровое пространство, включая информационные элементы интерфейса игрока. Если окно игры будет просто урезано до более мелкого экрана UMPC и другого форматного соотношения (в центре), то некоторые части игры будет невидно – здесь они показаны прозрачными полями по краям. Если окно игры будет просто урезано до более мелкого экрана UMPC и другого форматного соотношения (в центре), то некоторые части игры не будет видно – здесь они показаны прозрачными полями по краям.

Практический совет: всегда помнить о разрешениях 800x480 и 1024x600 при разработке пользовательских интерфейсов для MID, масштабируя исходное окно до размеров экрана или приспосабливая интерфейс так, чтобы он оптимально использовал широкоэкранный формат. Например, в некоторых случаях эффективным будет применение линеек прокрутки и разрешение изменения размеров окна (вручную или автоматически). Это даст пользователю доступ ко всему экрану и обеспечит ему приемлемые впечатления от использования приложения.

 

3.2 Фактор сенсорного экрана

 

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

 

3.2.1 Точная интерпретация ввода с сенсорного экрана только с нажатиями

 

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

 

 

 

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

 

3.2.2 Точная разметка сенсорного экрана

 

Проблема (разрешение окна меньше, чем физический экран): Когда приложение считает, что оно работает в полноэкранном режиме на разрешении меньшем, нежели физический экран, дисплей графического интерфейса может появляться в середине экрана с пустым пространством на его сторонах. Так происходит и когда окно 640x480 размещается в центре экрана 800x480, и когда окно 800x600 находится на экране 1024x600 - по сторонам возникают черные полосы. При этом может возникнуть несоответствие разметки экранов, когда вся сенсорная поверхность будет соответствовать относительно маленькой площади дисплея. Несоответствие приводит к неадекватному отклику интерфейса на пользовательские действия, - например, когда нажимаемая область кнопки не совпадает с видимым представлением кнопки.

 

 

 

 

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

 

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

 

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

 

 

 

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

 

Практический совет: разработчик должен быть уверен в том, что операционная система размечает сенсорный экран точно в соответствии с видимой областью экрана приложения (включая участки, не используемые при игре), и не включая участки игрового окна, которые не видны. Другое решение – изначально внедрить пользовательский выбор разрешений экрана (800x480 и 1024x600). В некоторых случаях возможно реализовать автоматическое растягивание окна до всего экрана, если нарушение пропорций элементов является приемлемым.

 

3.2.3 Альтернативы эффектам всплывания

 

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

 

 

 

 
Рис. 8 Эффекты всплывания.

 

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

 

3.2.4 Внедрение функций правой клавиши мыши

 

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

 

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

 

3.3 Проблемы форм-фактора

 

Ряд проблем связан непосредственно с отличиями аппаратного обеспечения MID от стандартных ПК. Например, в отличие от ПК, у MID может быть сенсорный экран, джойстик, программируемые пользователем и специальные клавиши, например, клавиши меню; и при этом у них обычно нет клавиатуры и CD-ROM. Хотя подключение клавиатуры, привода CD-ROM и других периферийных устройств может оказаться возможным, это снижает степень портативности MID. Более того, различные модели MID могут иметь различные элементы, что приводит к ограничениям, связанным с отличиями форм-факторов между этими устройствами. Эта разность обычно требует от разработчика сфокусироваться при создании приложения на наиболее часто встречающихся общих характеристиках оборудования, в смысле базовых требований к нему.

 

3.3.1 Ограничение числа способов управления

 

Проблема: Форм-фактор MID предусматривает ограниченное число средств ввода команд по сравнению с полной клавиатурой и мышью, доступных на стандартном ПК. Даже те игры, которые разработаны для использования на ПК с джойстиком, могут потребовать использования нескольких кнопок стандартного джойстика, которые не обязательно будут доступны на MID. Устройства MID также плохо работают с играми, в которых в качестве важного игрового элемента присутствуют «горячие клавиши». Однако игры, в которых основным средством управления является мышь, не так сильно страдают от ограничений в этой области, связанных с форм-фактором.

 

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

 

3.3.2 Решение проблем, связанных с клавиатурой

 

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

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

 

 

 

 
Рис. 9.  Экранная клавиатура при полноэкранном режиме.

 

4. Практические методы проектирования пользовательского интерфейса Hildon

 

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

 

 

 

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

 

4.1 Меню

 

Команды меню должны быть структурированы согласно их важности и функциональным взаимоотношениям. Если у вас много команд, попытайтесь сгруппировать функционально близкие команды в подменю и использовать на верхнем уровне только заголовки подменю, например 'Файл'->'Создать' и 'Файл'->'Сохранить'.

 

 

 

В интерфейсе Hildon схема меню – вертикальная, в отличие от горизонтальных схем в ПК-среде. Наиболее часто используемые команды или подменю должны быть расположены выше в меню, а наименее – внизу, так чтобы пользователи могли быстрее найти востребованные функции. Используйте разделители для объединения внутри меню связанных друг с другом пунктов. Избегайте использования более семи команд или заголовков меню вертикально и трех меню - горизонтально.

 

 

 

Команды, которые в данный момент не используются, должны быть отключены (показаны «серым»). Уникальное свойство Hildon – способность приложений реагировать также на выбор отключенных пунктов меню. Обычно в этом случае показывается информационный баннер, который объясняет, почему функция не работает. Например, «Нет действия для отмены». Это помогает пользователю правильно использовать приложение.

 

 

 

Для первого заголовка меню приложения используйте слово, которое связано с основной идеей программы – например, «Документ», «Изображение» или «Карта» вместо «Файл».

 

 

 

 
Рис. 10. Меню в Midinux.

 

4.2 Панель инструментов

 

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

 

  • Число пунктов в панели инструментов зависит от ширины каждого пункта и от того, показывается или нет Навигатор задач (переключение с обычного экрана на полный).
  • Если ваше приложение использует несколько видов экрана, то проанализируйте и оптимизируйте отображение функций в панели инструментов для каждого из них.
  • На панели должны быть представлены основные значки с базовой функциональностью.
  • Образы значков на панели инструментов должны быть понимаемыми, интуитивными и тесно связанными с действиями, на которые они ссылаются. Лучше всего, если они будут связаны с повседневной жизнедеятельностью, так чтобы пользователь мог ассоциировать задачи на устройстве с теми, которые знакомы ему из других ситуаций.
  • Все отображаемые команды должны быть доступны в меню приложения.
  • Из-за ограниченного размера экрана должна быть предусмотрена возможность скрывать панель инструментов командой из меню.
  • При необходимости для группирования значков следует использовать разделитель.
  • Избегайте использования на панели инструментов текста, который требует локализации, так как разная длина слов может нарушить макет панели. Везде, где это возможно, для экономии места на панели инструментов следует использовать значки, а не текст.

 

 
Рис. 11. Панель инструментов в Midinux. (браузер, плеер, E-mail, GPS, офисные средства, телефонная книга…)
 

 

4.3 Диалоги

 

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

 

 
 
Рис. 12.  Диалог в офисном средстве.

 

4.4 Уведомления

Уведомления используются для организации обратной связи с пользователем. Есть два типа уведомлений: сообщения и баннеры.

 

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

 

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

На рис. 3 показана разница между сообщениями и баннерами.

 

 
 
 
Рис. 13. Сообщение (слева) и баннер (справа)

Заключение

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

 

Справочная информация

[1] Передовые методы разработки игр для ультрамобильных ПК (Best Practices in Game Design for the Ultra-Mobile PC). Мэтт Гиллеспи (Matt Gillespie), Майкл Финкел (Michael Finkel) и Виктория Бэйли (Victoria Bailey)

[2] Краткое руководство по оформлению пользовательского интерфейса Hildon, версия 1.1 (Hildon User Interface Style Guide Summary Version 1.1).

[3] Руководство по проектированию пользовательского интерфейса приложения MID (MID Application UI Design Guide).