требования к экрану планшетного устройства для функционирования мобильного приложения
Первый ГОСТ для мобильных приложений
АНО «Российская система качества» (Роскачество) разработало и утвердило требования к мобильным приложениям для смартфонов. Это предварительный стандарт. Как сообщил СМИ заместитель руководителя Роскачества Илья Лоевский, это первый ГОСТ для России, поэтому в его основе лежат гайдлайны международных корпораций, к примеру, Google и Apple.
В официальном пресс-релизе Роскачества сообщается о том, что в рабочую группу технического комитета по разработке стандарта вошли специалисты ведущих компаний-разработчиков приложений и другие эксперты.
Остановимся на ключевых моментах.
Каким характеристикам должно отвечать мобильное приложение?
ГОСТ определяет 8 качественных характеристик, которым должно отвечать мобприложение:
Как разработчики должны описывать приложение?
Ключевые требования к юзабилити
Ключевые требования к безопасности
Как должны тестировать мобильные приложения?
Оценивать по каждому из критериев качества приложение будет эксперт. Типов тестирования три:
1. Экспертная оценка – тип тестирования, при котором экспертом оценивается степень соответствия свойств мобильного приложения конкретному критерию и выставляется оценка. При выставлении оценки эксперт руководствуется стандартом и проводит испытание на основании экспертного понимания предмета исследования.
2. Инструментальное тестирование – тестирование мобильного приложения экспертом с применением специальных инструментов и программного обеспечения с последующей конвертацией полученных результатов в балл по шкале от 0,5 до 5,5. При этом возможно тестирование одного и того же критерия различными инструментами и сравнение результатов в связи с тем, что не существует поверенных инструментов.
3. Ручное тестирование – тестирование мобильного приложения экспертом на мобильном устройстве без использования специальных инструментов или программных средств. В рамках данного типа тестирования эксперт использует мобильное приложение как рядовой пользователь, анализируя функциональность и работу приложения. По завершении ручного тестирования эксперт дает экспертную оценку по конкретному тестируемому критерию, основываясь на стандарте, экспертном понимании предмета исследования и опыте использования тестируемого приложения. Также ручным тестированием является получение общих сведений о мобильном приложении (таких как размер загружаемого распаковываемого пакета приложения, дата последнего обновления, пользовательский рейтинг и др.) из общедоступных источников (магазина приложений и сайта разработчика).
При формировании оценки, отличной от минимального и максимального значения по каждому из критериев, эксперт обязан пояснить в протоколе испытаний присвоенный им балл.
Кто такое эксперт по оценке приложений?
Это – специалист с высшим техническим образованием, имеющий опыт работы в качестве разработчика и/или аналитика информационных систем не менее 2 лет, прошедший курс подготовки, в рамках которого изучивший принципы разработки технических требований и ведения проекта создания и исследования качества (Quality Assurance, QA) программного обеспечения, имеющий опыт написания качественных технических требований и не имеющий личной заинтересованности в результатах исследований.
Обязательно владение английским языком на уровне чтения технической литературы.
Must-have документация для мобильного разработчика. Часть 1
Во время разработки приложений необходимо учитывать интересы сразу нескольких групп участников: заказчики (бизнес), проектировщики, тестировщики, разработчики и дизайнеры. Однако документация обычно готовится только для заказчиков, а про разработчиков и тестировщиков почему-то постоянно забывают. В нашей первой статье мы расскажем о том, как можно самостоятельно подготовить необходимый комплект документации, утереть нос проектировщикам и получить документацию, которая будет соответствовать коду, а не абстрактным бизнес-фичам.
Это серия статей «Must-have документация для мобильного разработчика»: Часть 1 и Часть 2.
Передаю слово Вячеславу Черникову.
В первой части мы расскажем о том, почему важно уделять внимание техническому проектированию и опишем необходимый минимум документации, которая позволит создать «скелет» проекта на основе пользовательского интерфейса.
Данная статья является сокращенной версией руководства, доступного по ссылке в конце статьи.
Первичная документация
Ключевую идею, с которой мы начнем, можно коротко сформулировать следующим образом:
Мобильные бизнес-приложение — это в первую очередь пользовательский интерфейс для взаимодействия с внешним сервисом.
При разработке технической документации на проект это стоит обязательно учитывать, так как интерфейс нагляден и на его основе проще проводить разделение проекта на разделы. Да и сама модель предметной области очень хорошо описывается интерфейсом — в ней необходимо учитывать в основном те данные (и их производные), которые вводятся пользователем, отображаются на экране и управляют его поведением. Бизнес-сценарии также напрямую завязаны на поведение пользовательского интерфейса.
В то же самое время большинство ТЗ готовится для бизнес-заказчиков и описывают не конкретные экраны или сервисы, а целые бизнес-сценарии и блоки функциональности. В дальнейшем эта документация и спецификации дизайна используются командой разработки. Для кодирования и последующей реализации используются многократные перечитки и пересказы ТЗ.
В следующих главах мы опишем минимально необходимый набор документов, которые позволят команде использовать простые чек-листы для контроля реализации.
Прежде чем мы перейдем к разбору артефактов и извлечению из них полезных данных, давайте рассмотрим весь процесс разработки целиком. Для простоты мы выберем линейный процесс разработки, так как при использовании циклических или спиральных методологий возникают те же самые классы задач, только последовательность их выполнения может отличаться.
Итак, у проекта обычно выделяют следующие производственные классы задач:
Можно выделить и больше, но они по факту будут являться производными от обозначенных.
На этапе аналитики производится поиск решения, описание общих требований к приложению. На выходе с этапа аналитики появляются спецификации, которые являются вводными для этапа проектирования.
Так как наше руководство предназначено в первую очередь для разработчиков, то считаем, что бриф или базовое ТЗ у вас есть.
Дальше начинается самое интересное – проектирование пользовательского интерфейса. Этот этап является ключевым и при правильном подходе очень сильно облегчает и упрощает процесс разработки. Если же данный этап пропущен, то дальше успех проекта будет зависеть только от опыта команды.
На этапе проектирования самым важным является продумывание пользовательского интерфейса и создание схем экранов.
Если начинать сразу с дизайна (вместо схем экранов), то придется постоянно переделывать его (дизайн) для согласования с заказчиком. На этапе проектирования это сильно замедлит процесс. Дизайн фактически является производным от UX и наполняет изначальные схемы эмоциями, выправляет композицию, добавляет анимации и другие аспекты внешнего вида и визуального поведения. Схемы экранов, в свою очередь, создают структуру приложения и моделей данных — какие данные отображать, как они будут сгруппированы, как они будут влиять на поведение интерфейса.
На выходе с этапа проектирования будет получен комплект необходимых спецификаций и ресурсов, которые вместе с ТЗ уйдут разработчику. Этап кодирования разумно начинать с построения фундамента – базовой структуры проекта, в чем нам очень поможет понимание ключевых пользовательских сценариев.
Экраны, данные и логика
Напомним еще раз, что мобильные приложения это в первую очередь пользовательский интерфейс, поэтому и проектирование лучше начать со схем экранов и последовательности переходов между ними. Это необходимо для того, чтобы определить набор шагов, которые предстоит пройти пользователю для получения желаемого результата. Ведь бизнес-приложение создается для определенного набора ключевых сценариев (последовательности действий пользователя), с помощью которых человек может решить свои задачи.
Так как среднее время контакта человека со смартфоном составляет всего несколько минут, то количество шагов в бизнес-приложениях не должно быть большим — для пользователя в первую очередь важно получить результат (выполнить задачу или удовлетворить потребность) за время контакта с устройством. Для сложных приложений с большим количеством функциональных возможностей следует учитывать этот фактор. Хорошим выбором станет разделение приложения на относительно короткие сценарии не более 10 шагов каждый.
Для того, чтобы определить глубину ключевых сценариев, можно использовать карту переходов и состояний, подробнее о которой будет рассказано в следующих разделах. Но для начала требуется привести в порядок структуру интерфейса.
Группировка экранов и сквозное именование
Итак, у нас на руках есть схемы экранов от проектировщиков/дизайнеров и последовательность переходов между ними.
Для того, чтобы разбить приложение на части (разделы предметной области), мы пойдем от экранов. Еще раз напомним, что мобильное приложение это в первую очередь интерфейс взаимодействия с пользователем, поэтому наши экраны и являются прямым отражением доступной ему модели предметной области.
Первым делом необходимо выделить экраны, которые связаны между собой, обычно они должны идти друг за другом в пользовательских сценариях. Например, часто в приложениях можно выделить раздел Account с просмотром и редактированием всей информации, связанной с профилем пользователя.
Если вы опытный программист, то легко справитесь с разделением списка экранов на связанные разделы. В любом случае, потребуется немного практики.
Итак, у нас могут получиться следующие разделы:
Каждый раздел должен иметь название и номер. Названия разделов следует использовать для горизонтального разделения слоя работы с данными, бизнес-логики и пользовательского интерфейса. Это позволит в дальнейшем проще развивать проект.
Например, слой работы с данными (группы методов для различных серверных API) в этом случае разделится на разделы (репозитории, если вам так привычнее), каждый из которых будет обслуживать свой набор экранов:
AccountDataService.cs (или AccountRepository.cs)
В дальнейшем каждый из репозиториев может полностью скрывать всю работу с сервером, дисковым кешем и локальной СУБД. Это позволит на уровне бизнес-логики работать с репозиториями как с черными ящиками.
Дальше предстоит пронумеровать и назвать экраны (страницы, окна). На выходе у нас получится древовидная (хотя и плоская) структура интерфейса без учета последовательности переходов между экранами и их вложенности.
Имена экранов будут использоваться у нас в названиях классов для соответствующих страниц (Page) и ViewModel (или Controller для MVС):
В первую очередь это важно для разработчиков, которые фактически получают готовую структуру проекта:
Как видим, уже вырисовывается скелет проект. Слой DAL можно легко выделить в отдельную библиотеку. Если же у вас используется типовая архитектура или шаблон проекта (Base-классы, NavigationService, и т.д.), то считайте, что костяк приложения у вас уже имеется.
Пример структуры проекта представлен ниже.
UI (User Interface, пользовательский интерфейс)
BL (Business Logic, бизнес-логика)
DAL (Data Access Layer, доступ к данным)
Для того, чтобы дальше реализовывать поведение экранов, нам потребуется дополнительная информация, поэтому продолжим знакомство с необходимыми артефактами.
Таблица экранов
После того, как у нас есть схемы экранов, мы также можем провести их анализ до фактического старта разработки. Следующим полезным артефактом для нас станет таблица экранов, оперировать которой будут не только разработчики, но и тестировщики. В сводной таблице легко собрать воедино всю текстовую информацию. Ключевыми столбцами таблицы для нас станут:
2. Краткое название (Name)
3. Список возможных состояний (States)
4. Поля ввода для валидации (Validation)
5. Описание экрана и его поведения (Behavior)
Как видим, в представленном наборе полей собрана та информация, которая позволит корректно проверить работу каждого экрана в отдельности. Можно также каждому разделу присвоить свой цвет — это упростит работу с картой переходов и состояний.
Дополнительно, в эту таблицу могут быть добавлены следующие столбцы:
6. Список всплывающих уведомлений (alerts, sheets, dialogs)
7. Идентификаторы UI-контролов (например, LoginButton) для написания автоматизированных UI-тестов
8. Используемые модели (Models/Data Objects) данных
9. Используемые на каждом экране методы DAL
10. Используемые стили (Styles)
О каждом экране по столбцам достаточно просто вписывать короткие обозначения, которые в дальнейшем будут использоваться в программном коде и понятны в первую очередь разработчикам. Кроме столбца Behaviour (Описание экрана и его поведение), здесь ограничений лучше не делать.
Отдельно остановимся на состояниях экранов. Большинство современных приложений работает через Интернет, поэтому стоит корректно отображать пользователю информацию о состоянии загрузки:
Хорошей практикой считается, если каждый экран, загружающий данные из сети (или из локальной СУБД) будет корректно отображать пользователю каждое из описанных состояний. Фактически, отдельное состояние описывается своим набором визуальных элементов (тексты, картинки, кнопки, другие элементы), и на уровне программного кода легко управлять переключением из одного состояния в другое. Также можно фиксировать негативные сценарии (ошибка загрузки, пустые данные) для дальнейшего анализа и устранения на стороне сервера или приложения.
Можно взять за правило и на всех экранах, загружающих данные, добавлять переключение состояний. Это упростит взаимодействие пользователя с приложением. Можно также использовать различные анимации или графику в негативных состояниях (ошибки, пустые данные), чтобы сгладить эффект.
Итак, у нас уже есть схемы экранов, список Page и ViewModel, а также детальная информация по каждому экрану. Каркас приложения можно построить, однако сейчас у нас экраны описаны независимо друг от друга и нет четкой и понятной последовательности переходов. Поэтому следующим полезным артефактом для нас станет карта переходов и состояний.
Карта переходов и состояний
Итак, карта переходов начинается с точки старта – момента запуска приложения пользователем. Точек старта может быть несколько, например, один вариант запуска для авторизованного пользователя, второй – для неавторизованного, а третий – из Push-уведомления.
Дальше добавляются прямоугольники для каждого экрана и обозначаются стрелками последовательности переходов. Можно добавить идентификаторы (AutomationId) кнопок или событий, из-за которых произошел переход, и для наглядности еще указать данные, которые будут передаваться на новый экран.
Также у нас уже есть таблица экранов (предыдущая глава), где обозначены возможные состояния каждого из них и которые необходимо отобразить на карте переходов. Это позволит лучше понять возможные прерывания пользовательских сценариев, например, в случае ошибок или пустых данных. Если состояние прерывает (человек не может идти дальше) пользовательский сценарий, то обозначаем его минусом «-», если не прерывает, то плюсом «+». Стрелочки «назад» можно не добавлять.
Как видим, теперь у нас имеется практически вся необходимая для разработки информация в компактном виде. Эти три онлайн-документа (список экранов, таблица экранов, карта переходов) могут обновляться по мере развития проекта.
Для создания описанных выше артефактов нам будет достаточно 3 онлайн-инструментов:
На подготовку каждого из артефактов уходит не больше одного дня, зато в дальнейшем это очень сильно упрощает процесс разработки, тестирования и развития продукта. За время медитативной подготовки документов и схем команда глубже понимает проект целиком и может уже финально оценить сложность и длительность его разработки (цифры для внутреннего использования).
Продолжение следует обязательно прочитать.
Полную версию руководства вы можете найти на Medium «Техническое проектирование мобильных приложений». Пообщаться напрямую с автором и сообществом Xamarin-разработчиков можно в нашем уютном чатике в Telegram.
Во второй части мы расскажем о том, как работать со стилями, фоновой функциональностью и пользовательскими сценариями. Оставайтесь на связи и задавайте свои вопросы в комментариях!
Об авторе
Вячеслав Черников — руководитель отдела разработки компании Binwell, Microsoft MVP и Xamarin Certified Developer. В прошлом — один из Nokia Champion и Qt Certified Specialist, в настоящее время — специалист по платформам Xamarin и Azure. В сферу mobile пришел в 2005 году, с 2008 года занимается разработкой мобильных приложений: начинал с Symbian, Maemo, Meego, Windows Mobile, потом перешел на iOS, Android и Windows Phone. Статьи Вячеслава вы также можете прочитать в блоге на Medium.
Другие статьи автора вы можете найти в нашей колонке #xamarincolumn.
Интерфейсы мобильных приложений: дизайн и эргономика
От переводчика. Продажи смартфонов и планшетов растут с каждым днем, и это уже говорит о необходимости повышенного внимания к интерфейсам для мобильных устройств. На каких принципах должен основываться дизайн приложений и сайтов для мобильных девайсов? Как удовлетворить все запросы пользователей, которые становятся все более и более требовательными?
По имеющимся прогнозам, в течение 2011 года объем продаж планшетов существенно возрастет, а объем продаж смартфонов существенно превысит объем продаж телефонов традиционного образца. Как показывает практика, пользователи предпочитают приложения для веб-навигации, уже установленные на телефоне, специальному программному обеспечению, которое нужно специально покупать или скачивать. Что это означает? В первую очередь — то, что в настоящее время перед веб-разработчиками и дизайнерами стоит задача учета особенностей мобильных устройств. Задача, следует заметить, не самая простая (см. статью известного специалиста в области веб-дизайна Якоба Нильсена «Мобильный контент: вдвойне сложнее» — www.useit.com/alertbox/mobile-content-comprehension.html, русский перевод- itopti.livejournal.com/2578.html, а также множество примеров дизайна на сайте www.mobileawesomeness.com ).
Cпециалист по юзабилити Патрик Кокс сформулировал 10 принципов, на которых должна основываться разработка мобильных приложений и сайтов www.ergonomie-interface.com/mobile-tactile-nomade/conception-site-web-mobile). Приглашаем читателей к обсуждению; будем рады, если кто-то сможет поделиться собственным опытом проектирования интерфейсов для мобильных приложений.
1. Используйте семантическую разметку
Мы знаем, что нужно всегда стараться отделить содержание от формы. Но при создании сайтов для мобильных устройств нужно двигаться еще дальше. Семантическая разметка обеспечивает лучшую сегментацию между формой и содержанием. Она обеспечивает лучшую доступность, позволяет уменьшить размеры файлов (и для этих файлов требуется минимум кода) и дает пользователю возможность лучше разобраться в содержимом веб-страницы.
Кроме того, если мобильный браузер не загружает изображений, JavaScript или CSS-стилей, сайт всегда будет отображаться должным образом и адекватно восприниматься пользователями.
1. Изображения улучшают понимание, но не являются самодостаточными для обозначения чего-либо. Представляйте изображения, используя свойства CSS бэкграунда или другие методы.
используйте тэги для обозначения типа содержимого: например, em для подчеркивания или abbr для обозначения аббревиатуры. Подробный список тэгов см. здесь: www.webdesignfromscratch.com/html-css/list-of-html-tags-with-semantic-usage
2. Пользуйтесь тэгом div только для выделения больших блоков материала, связанных друг с другом. Для выделения отдельных абзацев пользуйтесь специальными тэгами: ul для составления маркированных списков, span для выделения небольших блоков содержимого.
3. Помните о том, что семантическая паутина — это способ организации содержания, к стилю не имеющий никакого отношения.
2. Четко формулируйте задачу
Мобильная версия сайта должна быть предназначена для решения ограниченного числа задач. При ее создании необходимо особенно четко формулировать цели. Если место для сайта уменьшается на 80%, то и от 80% намеченных планов также придется отказаться. Функциональность мобильной версии сайта существенно ограничена по причине небольшого размера экрана. Например, в версию сайта для большого экрана можно запросто включить такие функции, как реклама новых продуктов компании, просмотре личных сообщений, заполнение небольших контактных форм, индикация последних сообщений в Твиттере и т. п. Но для мобильной версии такой вариант не годится: разместить все это на экране смартфона вряд ли получится. Уменьшение размера элементов содержимого — тоже не выход: не будет же пользователь просматривать сайт через увеличительное стекло!
Выход один: ограничиться наиболее необходимыми функциями, чтобы для них хватило места на экране.
Пример: сжатое и ясное представление информации на сайте
(мобильная версия портала bluemountain.ca ).
1. Работая над дизайном мобильной версии сайта, мыслите не в категориях страниц, а в категориях экранов. Каждый экран должен включать в себя не более трех функций или элементов.
2. Ориентация на упрощение экрана не только облегчает, но и помогает вам прояснить цели, задачи, функции, возлагаемые на мобильную версию сайта.
3. Избегайте перезаполнения!
Не стремитесь заполнять все пустые места на экране. У всех пользователей разная скорость соединения, поэтому сайт не должен «весить» слишком много. Избыточное количество изображений, текста, кода и т. п. не только ухудшает восприятие сайта пользователями, но еще и существенно увеличивает время его загрузки. Для пользователей мобильного Интернета важна оперативность: они не сидят перед компьютером, и обращение к тому или иному сайту необходимо им для решения срочных задач.
Пример: упрощенная и хорошо организованная горизонтальная навигация (http://m.journeys.com/).
1. Сведите количество изображений в мобильной версии сайта к самому необходимому минимуму.
2. Не включайте в мобильную версию сайта текстов большого объема.
3. «Облегчите» код посредством использования семантической разметки, а также сведения к минимуму числа CSS-стилей и вложенных файлов.
4. Не используйте выделенного состояния!
Навигация с помощью пальца или стилуса существенно отличается от навигации с помощью мыши и требует от разработчика большей изобретательности. Нужно использовать графические средства для того, чтобы продемонстрировать пользователю возможности управления тем или иным элементом.
1. Для обозначения ссылок используйте кнопки, а не подчеркивание текста.
2. Обозначайте доступ к более подробному содержимому при помощи стрелок.
3. В оформлении кнопок пользуйтесь оттенением и рельефными линиями.
4. Используйте знакомые и понятные иконки. Избегайте иконок непривычного вида для обозначения типов действий («добавить», «изменить», «назад», «вперед» и т. п.)
Пример: удачный вариант дизайна навигационных кнопок.
5. Пишите крупным шрифтом, просто и понятно
Даже на небольшом экране у пользователя не должно быть проблем с чтением текста. Если оптимальный размер шрифта для отображения на большом экране составляет 14 пунктов, то для мобильного устройства он должен быть как минимум в два раза больше. Следует, однако, учитывать, что чем крупнее шрифт — тем меньше информации удается разместить на сайте.
1. Мобильная версия сайта не должна включать никакой лишней информации.
2. Отбирайте тексты небольшого объема, написанные простым и понятным языком.
3. Не пользуйтесь функцией прокрутки без особой необходимости.
4. Включите в дизайн сайта кнопку «далее», нажав на которую пользователь сможет перейти к экрану с более подробным вариантом текста.
Пример: подача информации в виде кратких и емких текстовых блоков
6. Используйте элементы содержимого сайта в навигации
Особый интерес в создании версий сайтов, адаптированных под сенсорый экран, представляет возможность использования элементов содержимого в качестве элементов навигации: нажатие пальцем на ту или иную область экрана уже может стать инструментом для выполнения того или иного действия. В мобильных версиях сайта не нужно использовать, например, полосу прокрутки: ее функции возьмет на себя сам экран.
1. Пользуйтесь списками меню для перехода к подменю или другим экранам.
2. Проектируйте сайт как галерею экранов; применяйте творческий подход к организации прогулки посетителей по этой виртуальной галерее.
Пример: организация мобильной версии сайта как виртуальной галереи (сайт американской рок-группы Neon Trees).
7. Уделяйте внимание цветовой гамме
Экран мобильного телефона по размеру существенно меньше экрана стандартного монитора. Чтобы читать с такого экрана, нужно максимально приблизить его к глазам. Поэтому цвета мобильной версии сайта не должны быть слишком резкими.
Пример: минимум цветов и контрастность — залог удачного дизайна (http://world.g-shock.com/ ).
1. Не используйте без необходимости слишком яркие цвета в оформлении сайта.
2. Сайт не должен быть слишком «пестрым».
3. Используйте цветовую гамму, наиболее приятную для глаз.
4. Не забывайте о контрастах. На экране мобильного телефона контрастные цвета выглядят очень эффектно.
8. В общем стиле сайта главное — простота
Как визуальное решение сайта, так и его текстовое наполнение должны характеризоваться простотой и ясностью. В оформлении мобильной версии сайта следует избегать экстравагантных, нетрадиционных элементов. Используйте общеупотребительные слова, смысл которых будет однозначно понятен всем (например «имя пользователя» и «пароль», а не «ник» и «секретный код»).
Пример: форма для входа на мобильную версию сайта (социальная сеть для любителей пива Untapped- untappd.com/?mobile=true )
9. Обеспечьте возможность обратной связи
Браузеры для мобильных устройств поддерживают Java — воспользуйтесь этими и создайте пользователям возможность динамической обратной связи. Можно, например, показывать ход загрузки страницы с помощью анимации. Если пользователь забыл заполнить какое-либо поле, сообщайте ему об этом тотчас же. Создавайте диалоговые окна, информирующие пользователя о том, что происходит во время работы с сайтом.
1. При нажатии на определенную область экрана вид сайта должен изменяться (это служит подтверждением того, что нажатие действительно имело место).
2. Используйте JavaScript (к примеру JQuery или Scriptaculous) для организации полноценного диалога с пользователем.
3. Показывайте ход загрузки страницы с помощью анимации.
10. Сохраняйте пустые места
Большинство смартфонов имеют сенсорный экран, однако управлять сайтом исключительно при помощи пальцев гораздо сложнее, чем при помощи мыши. Вокруг кликабельных элементов сайта должно быть достаточного свободного места для того, чтобы пользователь мог нажать именно на них.
Пример — меню, удобное для навигации при помощи устройств с сенсорным экраном (мобильная версия портала www.charlesluck.com ).
1. Для обозначения ссылок используйте не подчеркивание текста, а кнопки, объекты, иконки.
2. Создавайте внутренние поля достаточных размеров, чтобы пользователь мог четко различать элементы.
3. Увеличение высоты строк делает текст более удобным для чтения на экране мобильного устройства.