Жанр: Учеба
Дизайн пользовательского интерфейса
...татуса.
Рис. 49. Статусная строка Adobe PhotoShop. Слева отображается текущий масштаб
отображения документа, вслед за ним объем занимаемой документом памяти (стрелка
переключает тип показываемой информации), затем индикатор степени выполнения,
а справа - контекстная подсказка (место оставалось, вот его и заполнили).
Строка статуса особенно интересна как место вывода индикатора
степени выполнения. Существует занятная закономерность: по месту
вывода индикатора выполнения можно определить качество интерфейса
системы: если индикатор выводится в строке статуса, то система обладает в
целом хорошим интерфейсом, если же индикатор выводится в другом
месте - не столь уж хорошим.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ОКНА
Панель инструментов для опытных пользователей.
Зачастую система
обладает функциональностью, которая с одной стороны важна, а с другой -
способна свести с ума неподготовленного пользователя. Обычно это каса
ется не столько собственно функций, сколько режимов работы системы, о
недостатках которых уже говорилось.
Так, любой не очень опытный пользователь MS Word, не имея под рукой
эникейщика, потратит как минимум минут пятнадцать на выход из режима
замены текста, предварительно нечаянно этот режим включив. Правильнее
всего, конечно, включать такие режимы из меню, рассчитывая, что пользо
ватель вряд ли выберет случайно элемент третьего уровня, но если в этот
режим надо входить часто, меню спасать перестает.
Рис. 50. Строка статуса MS Word. Первые два блока показывают положение открытого
фрагмента документа, за ними идут четыре переключателя режимов, затем кнопка,
нажатие на которую пролистывает документ до ближайшей языковой ошибки (это ещё
и индикатор системы проверки правописания).
В таких случаях строка состояния является отличным решением пробле
мы. С одной стороны, делая переключатели режимов непохожими на поля
вывода (знаете ли вы, например, что метки ЗАП, ИСПР, ВДЛ и ЗАМ в статусной
строке MS Word не только индикаторы?) можно снизить вероятность оши
бочного переключения. С другой стороны, если уж пользователь нечаянно
щелкнет на переключателе, он сразу же увидит изменение его вида и впос
ледствии, вероятно, сможет переключиться назад. С еще одной стороны,
опытный пользователь сможет переключаться между режимами так же
легко, как если бы он переключался через панель инструментов.
Панели инструментов
Все панели имеют следующие достоинства:
они позволяют пользователям быстро вызывать нужные функции
мышью
они позволяют пользователям меньше задействовать память
они повышают визуальное богатство интерфейса
они ускоряют обучение работе с системой (по сравнению с раскры
вающимся меню) благодаря своей большей наглядности.
Зато они имеют и недостаток: занимают много места на экране, так что
поместить в них всё, что хочется, невозможно. Решить эту проблему можно
двояко. Во первых, можно (и нужно) помещать в панель только наиболее
часто используемые команды (поддерживая это решение возможностью ин
дивидуальной настройки панели пользователем). Во вторых, панель можно
сделать зависимой от контекста действий пользователя. Оба способа не
противоречат друг другу, так что использовать стоит оба.
Панель инструментов нежелательно делать единственным способом
вызова функции
В настоящее время нет технической проблемы с помещением в панели
произвольных элементов управления (остался только один ограничитель -
размер помещаемых элементов), так что последние преграды, мешавшие
делать сложные панели, исчезли. Этим стоит пользоваться, поскольку это
позволяет экономить время, уходящее на открытие и закрытие диалоговых
окон, и повышать интегральное качество взаимодействия с системой
(пользователям нравится пользоваться сложными панелями).
Текст на кнопках. Самыми частыми элементами управления, размещае
мыми на панелях инструментов, является командные кнопки, при этом их
использование отличается от обычного. Дело в том, что места настолько не
хватает, что очень хочется заменить текст кнопок пиктограммами. Но это
не так просто.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ОКНА
Дело в том, что когда приходит время совершить выбор, имея в качестве
альтернатив визуальные объекты, "человек выбирающий" чаще всего
транслирует эти объекты в звуки, а именно в слова (в голове, разумеется).
Затем эти слова помещаются в кратковременную память, в дело включается
собственно сознание (предыдущие этапы проходят на бессознательном
уровне) и выбирает нужный объект. Применительно к реальной жизни это
значит, что пользователь, глядя на панель с пиктограммами, видит скорее
не пиктограммы, но слова. Но не всегда.
Случай 1. Опытный пользователь, уже знающий, где на панели
находится нужная кнопка, знающий её значение, при этом выбор
действия уже произведён при помощи сложившейся ментальной
модели. В такой ситуации слова пользователю уже не важны, важно
отличие нужной ему кнопки от остальных. Т. е. такому пользователю
даже уже все равно, что на пиктограмме изображено, лишь бы она
выглядела максимально контрастно (чтобы ускорить её поиск).
Случай 2. Опытный пользователь, обладающий сложившейся
ментальной моделью, но не знающий, где конкретно расположена
нужная ему кнопка и как она выглядит. Выбор действия уже произ
веден, осталось только найти нужную кнопку. При этом пиктограмма
оказывается ненужной, так как в качестве матрицы пользователь
использовать её не может (поскольку не знает, как она выглядит).
Более того, поскольку пользователь ищет слово из содержимого своей
кратковременной памяти, каждая пиктограмма будет его без пользы
отвлекать, при этом пользователь будет тратить время на
расшифровку смысла всех попадающихся ему на пути пиктограмм.
Случай 3. Неопытный пользователь без сложившейся ментальной
модели. Такой пользователь большую часть всего времени тратит на
поиск нужной ему кнопки, а также, поскольку каждая кнопка ему
внове, на постоянное улучшение своей ментальной модели системы с
учетом своих новых открытий. В таких случаях пиктограммы лучше
текста, но не заменяют его, так как помогают быстрее понять действие
кнопки (в том, разумеется, случае, когда пиктограмма адекватна
смыслу действия).
В результате таких рассуждений приходится прийти к странной мысли -
сначала кнопки на панели инструментов должны состоять из текста и
пиктограммы (чтобы легко было строить ментальную модель), затем, когда
пользователь свою модель построил, только из текста, а затем, когда
пользователь окончательно обучился пользоваться системой, только из
пиктограммы. Разумеется, построить такую систему невозможно, так что
приходится определяться. Поскольку в двух случаях из трех текст оказы
вается нужен (тем более что начинающие и средне продвинутые пользо
ватели составляют большинство), удалять его из панели оказывается
неправомерным.
Здесь действует ещё и вездесущий закон Фитса. Поскольку кнопка
с пиктограммой и текстом всегда больше кнопки с текстом или пикто
граммой просто, она оказывается более эффективной в отношении
скорости, поскольку в неё легче попасть мышью.
Таким образом, эффективнее всего (учитывая все аргументы за и против)
делать кнопки на панелях инструментов диалектически: самые главные
кнопки нужно делать парой "пиктограмма плюс текст", а остальные в
зависимости от их направленности - функции для опытных пользователей
пиктограммами, а для неопытных текстом.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ОКНА
Полосы прокрутки
и их альтернатива
Когда графических интерфейсов еще не было, пользователи перемещались
по документу с помощью клавиатуры. С тех далёких времен на клавиатуре
остались клавиши Home и End, равно как Page Up и Page Down. В целом,
пользователи были удовлетворены своей судьбой (благо, они не знали
альтернатив). Затем появились графические интерфейсы. Первым делом
были придуманы полосы прокрутки. К сожалению, оказалось, что они
работают не слишком хорошо.
Проблема полос прокрутки заключается в следующем: для маленьких
документов они не очень нужны, поскольку пользователям, держащим руки
на клавиатуре, гораздо легче переместиться к нужному фрагменту с по
мощью клавиш со стрелками. Напротив, в больших документах малое
перемещение ползунка приводит к существенному сдвигу области прос
мотра, так что после перемещения нужно еще и подправляться либо
клавиатурой, либо стрелками на полосе прокрутки. Более того: во многих
случаях невозможно реализовать динамическое изменение области
просмотра во время перемещения ползунка, а значит, перемещаться по
большим документам приходится в несколько шагов. И еще раз более того:
предположим, что это динамическое изменение всё таки есть. Тогда
пользователю нужно: сначала перевести взгляд на ползунок, затем курсор на
ползунок, затем взгляд на документ и только потом, перемещая мышь вверх
или вниз, следить за областью просмотра, на тему "не пора ли отпустить
курсор".
Пользователи ненавидят горизонтальные полосы прокрутки
Нечего и говорить, что пользователи избегают пользоваться полосками
прокрутки (тем более что курсорные клавиши никто с клавиатуры не
убирал). Фактически, чуть ли не единственным применением этих полосок
является перемещение "примерно к нужному фрагменту" при работе с
большими документами.
Разумеется, такое положение вещей никого особенно не радовало.
Поэтому было придумана "дополнительная стоимость" полосок - размер
ползунка был сделан пропорциональным отношению видимой части
документа ко всему его объёму. Это очень хорошая и полезная функция,
поскольку она позволяет использовать полосы прокрутки не только как
элемент управления, но и как индикатор размера документа, благодаря чему
степень бесполезности полосок значительно снижается. Помимо этого
было придумано довольно много других дополнительных стоимостей, так,
например, на полоске прокрутки можно отображать границы разделов
документа.
Полосы прокрутки без индикации размера документа практически
бесполезны
Тем не менее, всё это так и не сделало полосы прокрутки здорово лучше:
как и раньше, полосы не столько помогают перемещаться по документу,
сколько показывают то, что не весь документ помещается на экране.
Решение этой проблемы пришло с несколько непривычной стороны, во
всяком случае, графический пользовательский интерфейс не пригодился -
была придумана мышь с колесиком прокрутки. Решение это чуть ли не
идеальное, поскольку не требует от пользователя переносить внимание с
документа на элемент управления. Конечно, для перемещения по большим
документам колесо не слишком эффективно (палец устаёт), но малые и
средние перемещения получаются замечательно, тем более что процент
больших документов невелик. Поскольку мышь стоит не слишком дорого, а
служит не слишком долго, сейчас можно смело рассчитывать на наличие у
пользователей мышей с колесиком (я знаю двух людей, которые пошли в
магазин и купили себе новые мыши сразу после того, как увидели мышь с
колесом у сослуживца).
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ОКНА
Таким образом, полосы прокрутки стали совсем уж бесполезны, поэтому
относиться к ним надо не как к данности, но как к еще одному элементу
управления, который можно использовать, а можно и не использовать. При
этом есть как аргументы в пользу использования, так и существенный
аргумент против него - полоски прокрутки занимают много места на
экране. Ладно еще, когда на экране одна полоска, а что делать, если их три
или более?
С появлением мышей с колёсиками, полоски прокрутки смело можно
делать тоньше
К сожалению, вовсе не использовать полосы прокрутки в ПО затрудни
тельно, MS Windows User Experience прямо заставляет разработчика ими
пользоваться. В интернете ситуация иная - никто никого не заставляет.
Осталось разобраться, как же сделать пролистывание документа
идеальным.
Если всё таки приходится оставлять полосы прокрутки, крайне желатель
но добиться нескольких свойств полосок:
Размер ползунка должен показывать общий объем пролистываемого
документа.
Стрелки на полосах должны быть спаренными, т. е. обе стрелки долж
ны находиться рядом, а не на разных сторонах полоски. Это один из
случаев, когда логичность интерфейса вступает в противоречие с
эффективностью. Если при перелистывании была допущена ошибка,
спаренные кнопки позволяют минимизировать перемещение курсора
к стрелке, ведущей в обратную сторону (см. рис. 51).
Если невозможно сделать динамическое изменение области просмот
ра при пролистывании, необходимо показывать текущее место
положение пользователя во всплывающей подсказке (см. рис. 51).
Обратите внимание, что местоположение подсказки при переме
щении курсора должно оставаться неизменным.
Необходимо обеспечить обработку погрешности перемещения
курсора. Когда пользователь курсором перемещает ползунок, а
смотрит в это время на документ, курсор может сойти с полосы.
До определённого момента (смещение на 30 70 пикселей) система
должна такое смещение игнорировать.
Рис. 51. Два способа улучшить полоску прокрутки. Слева стандартная полоска, рядом
с ней полоска со спаренными стрелками. Справа: всплывающее сообщение, показы
вающее, какому фрагменту документа соответствует текущее положение ползунка.
Теперь об альтернативных элементах управления. Чаще всего исполь
зуются кнопки со стрелками, т. е. фактически полоски прокрутки, из кото
рых вырезано самое главное. Это не очень хороший элемент, потому что он
совершенно линеен: когда пользователь нажимает на кнопку со стрелкой,
документ листается с фиксированной скоростью, изменить которую
пользователь не в силах. Это приводит либо к медленному пролистыванию,
либо к низкой точности. Поэтому гораздо эффективнее малюсенький
джойстик, часто встречающийся в ноутбуках, который в народе ласково
называется клитором.
Сущность этого элемента проста: на экране располагается объект,
нажатие на который меняет курсор на изображение направленных в
разные стороны стрелок. Если пользователь перемещает курсор с нажатой
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ОКНА
кнопкой мыши в сторону, документ в эту же сторону и прокручивается,
причем скорость прокрутки пропорциональна расстоянию, на которое
перемещен курсор. Важно только не забывать его блокировать, когда
пролистывать нечего. Такой элемент управления в настоящее время
реализован в MS Windows и доступен по нажатию средней кнопки мыши.
Структура окна
Структура и само устройство окна или экрана является, пожалуй, самым
существенным фактором, влияющим на качество интерфейса в этом окне.
Например, производительность пользователей порой можно повысить
вдвое, просто изменив расположение элементов управления, не меняя сами
эти элементы.
Большинство руководств по проектированию интерфейсов, перечисляя
требования к структуре окна, ограничиваются замечанием, что термина
ционные кнопки (т. е. командные кнопки, управляющие окном, например
Ok
или Закрыть) должны быть либо снизу окна, либо в правой его части. Это
хорошо, но мало. На самом деле всё сложнее.
Во первых, окно должно хорошо сканироваться взглядом, т. е. его
основные части должны быть сразу видны и заметны. Как правило, в окнах
с малым количеством элементов управления проблем со сканированием не
возникает. Проблемы появляются в больших окнах, дающих доступ ко
многим функциям. Понятно, что сваливать эти функции в кучу неэффек
тивно, для этого интерфейсные элементы должны быть организованы в
блоки. В ПО для этого используются в основном рамки группировки, в
интернете - пустоты, разграничивающие отдельные функции. При этом
рамки удобнее в производстве, но, поскольку они являются визуальным
шумом, однозначно рекомендовать их нельзя. В целом, разграничивать
блоки пустотами предпочтительней (но и сложней).
Во вторых, окно должно читаться, как текст. При прочих равных, окно,
все элементы управления которого можно без труда связно прочесть, будет
лучше запомнено и быстрее обработано мозгом (поскольку не придется
преобразовывать грамматику окна в грамматику языка).
Рис. 52. Пример читаемого окна. Читается он следующим образом: "Текст выравнива
ется по левому краю, уровень пятый, отступ слева 3 см, справа 0 см, первая строка нет,
на 5 и так далее". На этом примере прекрасно видны все неопределенности в окне:
например, не говоря уже о том, что непонятно, чего именно пятый уровень, видно,
что подписи к "первая строка" и к "на", расположенные сверху, разрывают единый
по смыслу элемент управления на два разных.
При этом один элемент управления должен однозначно преобразовы
ваться в единый фрагмент предложения, а единая группа элементов -
в целое предложение.
Окно должно читаться, как текст
Проверить читаемость окна исключительно просто: окно нужно просто
прочитать. При этом становится понятно, какие нужны подписи к элемен
там, как они должны быть расположены и тому подобное.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ОКНА
В третьих, оно должно удовлетворять великому закону "релевантное -
вперед". Чаще всего используемые элементы должны быть расположены в
левой верхней части экрана, реже используемые - в правой нижней части.
Обратите внимание, что окно сканируется взглядом точно так же, как
происходит процесс чтения - сначала взгляд переходит в левый верхний
угол, затем перемещается вправо, затем переходит на следующую "строку"
и т.д. Поэтому, например, вертикальный элемент управления, разрываю
щий эти воображаемые строки на части, будет всегда замедлять сканиро
вание окна (и вызывать неудовольствие у пользователей).
Не забывайте проверять диалоговые окна на нормальную работу в
режиме Large Font
Теперь, возвращаясь к началу, пора объяснить, почему терминационные
кнопки должны быть расположены внизу или справа, тем более что здесь
действует всеобъемлющий закон. Дело в том, что в интерфейсе всегда долж
но быть реализовано правило: сначала выбор параметров, а затем действие
(интересно, что в большинстве языков ситуация обратная, например, мы
не говорим "Петю укусить", но говорим "укусить Петю"). Нарушение этого
правила существенно повышает количество человеческих ошибок и ослаб
ляет пользовательское ощущение контроля (что грозит низким субъектив
ным удовлетворением). Это правило, будучи применено к диалоговым
окнам, и заставляет помещать терминационные кнопки снизу или справа,
т. е. в области, которая сканируется последней.
Увеличиваем
площадь
Площадь экрана ограничена, напротив, количество элементов управления,
которых может понадобиться уместить в едином функциональном блоке
(т. е. окне), не ограничено ничем. В этом случае приходится использовать
вкладки (см. рис. 52). Чтобы правильно их использовать, нужно соблюдать
определенные требования.
Первая вкладка и остальные вкладки. Помимо умещения максималь
ного количества элементов управления в диалоговом окне, вкладки могут
выполнять еще одну роль, а именно скрывать от неопытных пользователей
не очень нужную им функциональность. Проблема заключается в том, что
когда нужно просто уместить в окно побольше элементов, вкладки скрыва
ют от пользователей функциональность, возможно, что и нужную.
Некогда в Windows было два способа поместить в диалоговое окно боль
ше, чем в него могло влезть. Можно было воспользоваться вкладками, а
можно было нажать на специальную кнопку, которая увеличивала размер
окна и открывала доселе скрытые элементы управления. Microsoft эти кноп
ки разонравились и, начиная с Windows 95, она планомерно удалила их из
почти всех своих продуктов, заменив вкладками.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ОКНА
Рис. 53. Увеличивающееся диалоговое окно. Сверху начальное состояние окна,
снизу - конечное. Нажатие на кнопку More Choices увеличивает окно. Это диалоговое
окно интересно тем, что для открытия полного окна пользователям приходилось нес
кольку раз нажимать на кнопку. Это плохо, поскольку, чтобы узнать о существовании
дополнительных критериев поиска, пользователям приходилось совершать слишком
много действий. Неудивительно, что в последних версиях MacOS эта утилита была
полностью переработана. Apple
Это и породило проблему. Раньше разные вкладки содержали примерно
одинаково важные элементы, просто не все помещались в одно окно, а
кнопка с треугольником скрывала элементы, про которые начинающий
пользователь твердо знал, что они ему не нужны или пользоваться ими
опасно. Теперь все во вкладках, поэтому пользователи часто уверены, что
сразу невидное опасно.
В результате некоторые пользователи избегают пользоваться элемента
ми, расположенными на изначально закрытых вкладках, даже если это
ничем им не грозит. Поэтому нежелательно размещать на закрытых
вкладках элементы, которые пользователям обязательно понадобятся, даже
если эти элементы и не нужны постоянно (в этом случае правило про
релевантность должно отступать). Разумеется, это не касается опытных
пользователей.
В интернете и в остальных операционных системах, которым Microsoft
была не указ, кнопки, увеличивающие размер окна и открывающие продви
нутые элементы управления, сохранились в полном объеме. Учитывая тот
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ОКНА
факт, что никаких пользовательских проблем с ними не замечено, можно
смело рекомендовать их и для использования в Windows, тем более что они
позволяют добиться определенного брэндинга.
Похоже, что Microsoft сама осознала вред от потери увеличивающихся
окон, вызванный недоверием пользователей ко вкладкам. Во многих про
дуктах она стала использовать несколько усложненный элемент управления
TreeView, также позволяющий запихнуть очень много элементов в ограни
ченное пространство. К сожалению, TreeView, если вместить в него допол
нительные элементы управления, крайне неудобен в обращении1, так что
похвалить Microsoft за использование этого элемента затруднительно.
Число вкладок.
Теоретически число вкладок может быть сколь угодно
большим. На практике оно ограничивается двумя факторами: во первых,
объемом КВП (см. "Кратковременная память" на стр. 47), а во вторых,
размером области, в которые ярлыки вкладок могут помещаться. Дело в
том, что если ширина всех ярлыков будет больше ширины окна, придется
либо делать несколько строк ярлыков, либо скрывать часть из них, пока
пользователь не нажмет специальную кнопку. И то и другое плохо.
Рис. 54. Пример нескольких строк ярлыков. Если пользователь щелкает по ярлыку из
верхнего ряда, весь этот ряд становится нижним, нижний же перемещается вверх. При
этом две строки есть вовсе не предел - порой встречаются диалоговые окна с тремя
рядами ярлыков. Microsoft
Несколько строк ярлыков плохо по двум причинам. Во первых, из за
большого количества мелких деталей (границ ярлыков), вся конструкция
довольно медленно сканируется, т. е. трудно найти нужную вкладку. Во
вторых, при последовательном обращении к нескольким вкладкам из
разных рядов эти ряды меняются местами, т. е. каждый раз нужно заново
искать нужную вкладку. И то и другое крайне негативно сказываются на
субъективном удовлетворении и скорости работы.
Рис. 55. Пример частично скрытых ярлыков вкладок. Selenic Software
Скрывать часть ярлыков тоже нехорошо. Предположим, что пользова
тель нажал на стрелку вправо, показывающую следующую часть ярлыков.
Если при этом значительно пролистывать строку с ярлыками, пользователи
будут полностью потерять контекст (сильнее даже, чем они теряют его,
нажимая Page Down). Если же пролистывать строку по одному элементу,
контекст не потеряется, но перемещение между вкладками будет очень
медленным.
Существует и третий способ решения проблемы - можно просто убрать
вкладки, заменив их раскрывающимся списком. Этот способ тоже не слиш
ком хорош, поскольку не слишком визуален и к тому же сравнительно
медлителен.
. Я не включил в книгу описание этого элемента именно потому, что имеющиеся
TreeView неудобны и непонятны многим пользователям. Возможно, что они
эволющионируют во что то приличное, но пока правило просто: если вам нужна
скорость работы или пользователи не имеют большого опыта, избегайте
TreeView всеми силами.
WWW.UIBOOK.RU | ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ОКНА
Похоже, что самым эффективным решением является комбинация
второго и третьего способов: основные экраны реализуются в форме
вкладок, а дополнительные вызываются через раскрывающийся список.
Это позволяет обеспечить максимальное количество наглядности и
скорости работы.
Объем содержимого. Фактически, каждая вкладка представляет собой
отдельное диалоговое окно внутри другого диалогового окна. Поэтому
странной выглядят попытки (встречающиеся огорчительно часто)
рассортировать элементы управления так, чтобы во всех вкладках их было
поровну. Делать это ни в коем случае нельзя. Один экран должен содержать
только те элементы, которые в нем нужны и которые пользователь может в
этом экране ожидать.
Не старайтесь рассортировать элементы так, чтобы в каждой вкладке их
был одинаковое количество
Терминационные кнопки.
В диалоговом окне с вкладками терминаци
онные кнопки обязательно должны располагаться вне области вкладок.
Перемещение
в пределах окна
Помимо навигации между экранами, существует еще и навигация внутри
отдельных экранов. Пользователям необходимо дать возможность макси
мально быстро переходить к необходимым элементам управления. Для
этого у них есть два способа - мышь и клавиатура.
С мышью все более менее понятно: закон Фитса (см. "Быстрый или
точный" на стр. 10) работает на полную катушку. Поэтому оптимизация
диалогового окна, уменьшающая дистанцию перемещения курсора, всегда
приводит к росту (хотя и небольшому) производительности пользователей.
С клавиатурой сложнее. Пользователь может перемещаться межд
...Поділитися у соцмережах
