Когда я рассказываю о своих исследованиях редактирования текста на мобильных в Google, то обычно сталкиваюсь с непониманием и немного враждебным «Разве на телефонах нельзя редактировать тексты? В чём проблема?»
Редактирование текста на мобильных поломано. На самом деле, оно гораздо хуже, чем вы думаете, это невидимая проблема, на которую никто не обращает внимания. Я написал этот пост, чтобы вы поняли, насколько это важно. Так как проблема имеет много нюансов, вам может наскучить чтение, поэтому я разбросал по тексту множество заголовков; если надоест, просто пропускайте раздел.
TL;DR
У Android и iOS есть одна общая проблема: они скопировали методики работы с текстом с десктопов, но у них нет панели меню и мыши. Это заставило их перегрузить жесты касаний огромным спектром действий: размещением курсора, его перемещением, выделением текста и вызовом всплывающего меню. В результате касания получились слишком сложными и неоднозначными, что приводит к разнообразным пользовательским ошибкам.
Это почти не проблема, если ваш ввод ограничивается короткими текстами в соцсетях или мессенджерах. Но ввод чего-то более сложного, например, электронного письма, становится утомительным. Однако в моём исследовании пользователей я неожиданно обнаружил, что у всех них есть существенные проблемы и достаточно сложные обходные решения для редактирования текста.
Вместе с невероятно талантливым Оливье Бау мы создали прототип под названием Eloquent, обеспечивающий гораздо более простое решение. Мы представили эту работу на UIST 2021.
Да, редактирование текста — это проблема
Когда я работал на Android в 2017 году, у меня возникли вопросы о редактировании текста и я начал искать исследования пользователей. Я предполагал, что настолько фундаментальный для пользователей процесс должен был исследоваться хотя бы несколько раз. Изучив исследования за семь лет, я не смог найти ни одного, посвящённого редактированию текстов. Меня это поразило.
Редактирование текста на мобильных считается «достаточно хорошим». Люди не жалуются, поэтому и почти нет мотивации к его совершенствованию. Однако я решил провести собственное исследование, и результаты меня удивили. Я выдал десяти участникам простой набор задач по редактированию текста, например, «удалить “x” из строки символов» или «переместить слово в конец предложения». У каждого из участников возникали проблемы с прицеливанием, использованием буфера обмена и с кучей ошибок.
Я спросил участников о том, насколько удобно для них редактирование текста на мобильных устройствах. Все они высказали раздражение, но в основном связанное не с мессенджерами или соцсетями, где они обычно пишут лишь короткие тексты. Сложности вызывало составление более сложных текстов, например, электронных писем из множества предложений. Они часто говорили что-то вроде «Я часто начинаю ввод на телефоне, но если всё становится слишком сложно, то просто заканчиваю на ноутбуке». Ещё более удивительным оказалось то, что больше половины участников заявили, что вместо редактирования текста было проще выделить всё, удалить и ввести заново, полностью отказавшись от редактирования. И это признак того, что в чём-то есть проблема.
Уточню: проблема заключается не в вводе текста, а в его редактировании. Клавиатуры стали лучше, появилась транскрипция голоса, на многих планшетах есть физические клавиатуры, поэтому ввод текста в устройство уже перестал быть такой сложностью. Однако после этого его всегда приходится редактировать.
Хотя моё исследование посвящено решению проблем редактирования текста в Android, должен сказать, что iOS, имеющей существенные отличия в редактировании текста, всё равно содержит многие из аналогичных проблем.
Редактирование текста — это хак
Мобильные устройства изначально проектировались для потребления. Революция скроллинга пролистыванием упростила перемещение по контенту. Сверхсила мобильных заключается в их возможности потреблять видео, фотографии, соцсети и мессенджеры на ходу. Это ценные задачи, но они почти не требуют редактирования текста. Люди забывают, что в первом iPhone даже не было поддержки буфера обмена!
Однако последние десять лет мы часто слышим, что рано или поздно люди начнут использовать планшеты для всего. Несколько лет назад Apple выпустила рекламу «What’s a computer?», а в 2013 году Google попыталась провести кампанию «планшетные вторники», чтобы убедить своих сотрудников постоянно использовать на работе планшеты. Планшеты по-прежнему продаются достаточно неплохо, но в качестве замены десктопным компьютерам имеют, скажем так, довольно умеренный успех.
Об этом достаточно часто пишут, я не говорю ничего нового. Однако люди, похоже, не могут прийти к согласию относительно причин этого. Дело не в том, что некоторые люди не могут продуктивно работать с планшетами. Очевидно, что есть люди, которым это удаётся. Но не большинству. Почему же?
Вероятно, на то есть много причин, но я бы сказал, что существуют глубокие фундаментальные проблемы с UX планшетов, мешающие продуктивности. Одна из них — редактирование текста. Ещё одна — это работа с файлами, если вам интересно, то я уже писал об этом. Однако прежде чем кто-то заявит, что я ностальгирующий дурачок, должен сказать, что я не настроен против мобильных. Моя цель — не возвращение к десктопам, а развитие мобильных. Как же исправить наши телефоны и планшеты, чтобы мы могли быть столь же продуктивны и быстры, как и на десктопах?
Начинаем с редактирования текстов на десктопах…
Редактирование текста на десктопах имеет долгую и интересную историю, но давайте сосредоточимся на интервале после 2000 года, когда ситуация начала стабилизироваться. В каждой десктопной операционной системе есть курсор мыши, который можно точно перемещать мышью или трекпадом, что позволяет с лёгкостью нажимать на нужный вам символ.
Выделять текст тоже достаточно просто: зажав кнопку мыши, нужно перетащить её, и курсор выделит больше текста. Также есть меню «Правка» с классическими командами Вырезать/Копировать/Вставить, позволяющая работать с выделенным текстом. Для ускорения работы есть горячие клавиши X, C и V.
Сочетание этих трёх особенностей — точного указателя, простого выделения и меню с горячими клавишами — упростило редактирование текста, позволило избавиться от ошибок и неоднозначности. Если быть откровенным, можно представить, как улучшить эту систему, и я не хочу настаивать, что она идеальна. Мы просто используем её как отправную точку для сравнения с редактированием текста на мобильных.
… а затем ущербно её копируем
Учитывая то, насколько доминирующим был десктопный UI в момент появления мобильных платформ, неудивительно, что дизайнеры попытались скопировать редактирование с десктопов. Проблема заключалась в отсутствии указателя мыши и панели меню с горячими клавишами. Из-за этого разработчикам пришлось пойти на существенные компромиссы.
Например, вместо нажатия курсором мыши на мобильных нужно касаться пальцем. Это значит, что прицеливание курсором текста оказывается чуть менее точным. В исследованиях UX это хорошо известное явление называется проблемой «толстых пальцев». Именно поэтому в рекомендациях по созданию пользовательского интерфейса рекомендуется делать кнопки достаточно высокими и широкими, потому что в большие мишени проще попасть. Однако символы текста невозможно сделать достаточно большими. Обычно это приводит к тому, что текстовый курсор оказывается немного левее или правее, чем нужно.
Проблема прицеливания привела к появлению каскада новых механизмов взаимодействия, которые решают проблему, но имеют неприятные побочные эффекты.
Четыре изменения, внесённые мобильными в редактирование текста
1. Маркеры текста
На мобильных появились маркеры в виде капли снизу от текстового курсора. Они позволяют проще разглядеть текстовый курсор и в случае промаха перетаскивать курсор в нужное место. Кажется вполне логичным, так ведь?
Но на самом деле это не так! Это создаёт нашу первую неоднозначность. Маркер текста сам по себе становится целью для касания. К сожалению, ею остаётся и окружающий его текст. Теперь у нас есть две потенциальные цели для касания. Если они далеко друг от друга, это нормально. Проблема возникает только тогда, когда я хочу коснуться места непосредственно слева или справа от текстового курсора. В таком случае непонятно, чего хочет пользователь: переместить курсор или коснуться маркера/перетащить его.
Мы наблюдали это в нашем первом пользовательском тестировании, когда пользователи пытались точно разместить текстовый курсор: они промахивались на несколько символов и касались снова чуть сбоку, но приоритет получал маркер текста и «воровал касание», ошибочно предполагая, что пользователь хочет его перетащить. На десктопе в случае нажатия не в то место можно просто снова нажать для перемещения курсора, никакой неоднозначности нет. Хотя такая ситуация и не катастрофична, она усложняет работу. Хуже того, это лишь начало тенденции. Когда мы доберёмся до остальных изменений, эта неоднозначность при вводе будет только усугубляться.
В iOS нет маркера в виде капли, но текстовый курсор всё равно создаёт ту же проблему «воровства касания».
2. Лупа
Так как текст на мобильных устройствах очень мал, а палец относительно него велик, в мобильных устройствах добавили лупу.
У лупы есть две проблемы. Во-первых, она не особо помогает перед касанием для размещения курсора, она больше помогает исправить ошибку. Она реализует это, делая видимым то место, куда вы выполняете перетаскивание. Во-вторых, она сбивает с толку визуально. Плавая над пальцем, она создаёт два видимых курсора: реальный под пальцем и его дубликат в лупе. На самом деле, это не очень плохо в случае коротких текстовых полей, но при работе с длинными электронными письмами становится легче потеряться и не понимать, где в тексте вы находитесь.
Лупа Apple, исчезнувшая в iOS 13 и вернувшаяся в iOS 15, ещё более хаотична.
3. Выделение текста
На десктопах выделение текста стало естественным расширением функции щелчка мыши: удерживая кнопку, мы выполняем перетаскивание. На мобильных это невозможно, поэтому появился совершенно новый жест: двойное касание. Постойте, но на самом деле есть и третий жест — долгое нажатие, которое тоже работает. И оба жеста выполняют одну задачу. Не смотрите на меня так, не я это проектировал…
Однако этот новый жест вызывает ещё больше затруднений: для декодирования «двойного касания» системе нужно немного подождать, чтобы понять, не последует ли второе касание, поэтому обычно это откладывает эффект одного касания. Это значит, что маркер текста может «своровать касание» ещё одним способом.
Однако выделение на этом ещё не завершается, ведь часто вам нужно выделить несколько слов. Для решения этой проблемы маркер текстового курсора находится на обеих сторонах выделения. Это позволяет расширить выделение, перетащив любой из концов. То есть выделение нескольких слов — это двухэтапный процесс: мы выделяем слово, а затем перетаскиваем маркеры выделения. Этот составной набор жестов для редактирования текста, как и описанное выше размещение курсора, не ужасен, но не сравним по элегантности с десктопным, и он определённо повышает сложность работы.
4. Всплывающее меню
Так как на мобильных устройствах нет панели меню, мы каким-то образом должны вызывать команды буфера обмена. Это делается двумя способами. Первый наиболее очевиден: как только произошло выделение текста, показывать над выделением меню. Это немного перегружает ввод визуально, но не создаёт никакой неоднозначности касаний. Такая система неплохо работает для вырезания/копирования, но проблематичнее для вставки, которая обычно не начинается с выделения. Решение немного неочевидно: вызвать то же самое меню можно, коснувшись маркера текста. Это значит, что пользователям нужно изучить ДВА жеста для открывания меню. В iOS ситуация примерно такая же.
Эта проблема усугубляется в Android, поскольку маркер текста пропадает спустя четыре секунды неактивности. Причина этого в том, что маркер слегка закрывает текст под ним. Это делает меню совершенно недоступным. Если вы хотите открыть меню, то необходимо снова коснуться для появления маркера, а затем коснуться его во второй раз. Неудивительно, что людей это сбивает с толку.
Эта система «меню при касании маркера» добавляет ещё одну неоднозначность с прицеливанием. Распространённая проблема попыток разместить курсор заключается в том, что пользователь случайно касается маркера, который открывает меню.
Для опытных пользователей ситуация усугубляется из-за отсутствия аналогов горячих клавиш для вырезания, копирования и вставки. Вне зависимости, новичок вы или эксперт, вам нужно использовать меню одинаково. Представьте, что на десктопе каждому бы приходилось использовать меню «Правка» для вырезания и вставки текста. Это очень ленивый дизайн. Хоть мы и должны всегда в первую очередь заботиться о новичках, не стоит игнорировать опытных пользователей. Буфер обмена на десктопах используется так часто ещё и благодаря скорости. На мобильных ничего подобного нет.
Как можно ошибочно интерпретировать касание
Эти дополнительные хаки, привязывающие десктопное редактирование текста к мобильным, функциональны и выполняют свою работу, но каждый из них добавляет ещё один способ ошибочной интерпретации касания. При каждом касании пользователя может произойти одно из этих действий:
размещение курсора
открытие меню (если курсор уже есть)
начало перетаскивания
начало двойного касания
начало долгого нажатия
Если вы действуете крайне осмотрительно, этими отдельными действиями можно управлять. Ситуация далека от катастрофичной. Однако я считаю, что такая система очень хрупка. Она может неприятно удивить пользователя слишком многими способами. Вот некоторые из ошибок, которые я наблюдал при пользовательском тестировании:
Проблема 1: когда пользователь касается экрана, то из-за проблемы толстых пальцев он не попадает в нужное ему место.
Проблема 2: если он коснётся чуть сбоку, чтобы правильно разместить курсор, то касается маркера текста и появляется меню, сбивая его с толку. Он вынужден коснуться другого места, чтобы закрыть меню и попробовать снова.
Проблема 3: вместо открытия меню второе касание интерпретируется как тривиальное перетаскивание и ничего не происходит.
Проблема 4: если пользователь пытается совершить двойное касание, но касается немного сбоку или попадает по маркеру текста, то операционная система понимает его неправильно и ничего не происходит.
Проблема 5: пользователь хочет вставить текст в пустое поле, но сбит с толку, ведь текстового курсора и меню нет. Ему сначала нужно коснуться пустого поля, чтобы появился курсор, а ЗАТЕМ коснуться курсора во второй раз, чтобы открыть меню.
Проблема 6: пользователь касается, чтобы поместить курсор, но на секунду поднимает взгляд, чтобы прочитать беседу. За эту короткую паузу срок действия маркера текста истекает и он пропадает. Посмотрев вниз, пользователь хочет коснуться маркера, но не видит его и запутывается. Он вынужден коснуться поля снова.
Все эти сложности начинают суммироваться. Каждое из этих изменений по отдельности кажется разумным. Однако взятые вместе они добавляют существенную долю ошибок и сложностей в процессе. В моём исследовании десяти пользователей для точного размещения курсора в среднем требовалось пять попыток. Одному пользователю пришлось сделать 19 касаний! Поэтому неудивительно, что многие из наших тестовых пользователей просто отказывались от редактирования текста, предпочитая вместо этого ввести всё заново.
Очевидно, редактирование текста на мобильных возможно, ведь ежедневно этим занимаются миллионы людей. Я не утверждаю, что «это невозможно», скорее считаю, что «это гораздо сложнее, чем мы думаем». Многие из вас могут сказать «соберись, дедуля, это не так уж тяжело», и сбросят мои размышления со счетов. Но помните о том, что основная часть текстов на мобильных коротка и не требует усилий, обычно это сообщения и комментарии в соцсетях. Редактирование необходимо редко, поэтому эти трудности не особо важны. Кроме того, многие люди говорили мне о студентах, писавших на телефоне целые статьи. Да, это возможно! Многие люди бегают марафоны, но это не значит, что на это способны все.
Если не верите, попробуйте поредактировать большие тексты в Android или iOS. Просто надиктуйте голосовым вводом абзац и попробуйте его подчистить. Обратите внимание на количество ошибок, а затем честно скажите мне, был ли это простой и удобный процесс.
Если мы хотим, чтобы мобильные заменили десктопы (или хотя бы конкурировали с ними), они должны вырасти над этими хаками с касаниями во что-то спроектированное специально под мобильные. Вместо того, чтобы криво копировать десктоп, мы должны использовать сенсорный интерфейс для создания чего-то плавного, чёткого и гораздо более простого.
Eloquent: один из путей развития
Прежде чем я расскажу в подробностях об Eloquent, мне бы хотелось подчеркнуть, что основная цель поста — полное описание проблемы. Я хотел сделать эту невидимую проблему видимой для вас. Многие не осознают, насколько она глубока. Учитывая это, надеюсь, все мы согласимся, что нужно какое-то решение. Вы можете не согласиться на Eloquent, и это нормально. Надеюсь, кто-то придумает другие, более совершенные решения.
Так как этот пост и так уже оказался довольно длинным, ниже я перечислю основные функции, которые мы попробовали, но более подробную демонстрацию наших попыток стоит посмотреть в ознакомительном видео, которое я сделал для UIST. Так как проблема включает в себя коллизию между касанием, выделением, лупой и пользованием меню, сложно решить проблему, не поработав одновременно над всеми четырьмя.
Упрощённое размещение курсора
Наша основная цель заключалась в создании действия касания, не имеющего никаких неоднозначностей, по простоте схожего с щелчком мыши на десктопах. Мы хотели, чтобы касание всегда размещало курсор. Как говорилось выше, одна из проблема современных маркеров текста в том, что они «воруют» курсор, думая, что это начало перетаскивания или открывания меню. Мы обобщили эту логику, чтобы каждый раз, когда палец касается экрана, это считалось началом перетаскивания. Касание — это просто очень короткое перетаскивание. Это значит, что если коснуться бока маркера и быстро поднять палец, то курсор перейдёт в новое место; однако если перетаскивать медленно, то курсор перетащится в то же место. Проблема решена.
Визуально мы всегда оставляем маркер текста видимым. Мы не хотели, чтобы он появлялся и исчезал. Это мотивирует пользователей выполнять перетаскивания, которые более точны, чем касания. Мы сделали маркер полупрозрачным, чтобы он не перекрывал текст. Это сделало курсор визуально стабильным и устранило таймауты в четыре секунды.
Единая лупа
Интегрировав лупу над текстовым курсором, мы упростили визуальное представление, чтобы пользователь всегда смотрел на курсор в контексте. Так как в Eloquent настолько важно перетаскивание, это улучшает общее удобство пользования и мотивирует к перетаскиванию. Мы используем технику рыбьего глаза, чтобы экономить место и позволить пользователю ориентироваться в его тексте.
Однако такой подход поставил нас в неожиданное положение: на самом деле лучше ВСЕГДА перетаскивать курсор, так как лупа позволяет выполнять гораздо более точное размещение текстового курсора. Продолжив пользоваться этой системой, мы начали сразу же выполнять перетаскивание и сужать его, приближаясь к цели. Это новое поведение, но мы выяснили, что адаптироваться к нему можно очень быстро.
Нажатие перетаскивания для выделения текста
Основная причина такого высокого уровня неразберихи сегодня заключается в том, что используется один жест касания. Это создаёт наблюдаемые нами неоднозначности. Поэтому мы создали новый жест, выполняемый при перетаскивании: более сильное нажатие при перетаскивании. Этот жест запускает выделение текста. Мы использовали датчик барометрического давления в телефоне, чтобы определять, когда пользователь нажимает. Мы выбрали его, потому что тогда это был единственный доступный нам аппаратный датчик. Мы сохраняли два скользящих средних, одно для базового измерения, и одно короткое для запуска события. Когда короткое среднее поднималось выше длинного среднего, мы запускали событие нажатия перетаскивании. Система оказалась на удивление надёжной и работает достаточно хорошо, хотя показания датчика достаточно сильно варьируются. Более совершенным решением мог бы быть прогрессивный механизм наподобие 3D Touch, от которого, к сожалению, Apple отказалась.
Улучшенные меню
Наконец, мы попытались реализовать более удобный жест, чтобы опытные пользователи могли добиться так нужной им скорости при работе с копированием/вставкой. Так как почти каждое современное меню (и в Android, и в iOS) иерархично, мы хотели воспользоваться этой возможностью, чтобы сделать меню плоским. Это не являлось критичной целью, но было настолько ужасным преступлением против UX, что мы должны были устранить и его тоже. Мы хотели хотя бы попробовать придумать что-то более удобное для просмотра. Все наши тестовые пользователи посчитали эту систему удобной и им понравилось с ней работать.
Кроме того, после того, как нажатие перетаскивания запускает выделение, второе нажатие перетаскивания открывает меню. Это позволяет выполнять прицеливание, выделение и открытие меню одним плавным жестом. Есть и функция для опытных пользователей — быстрое пролистывание для вызова пункта меню. Оно позволяет использовать на мобильных приблизительный аналог горячих клавиш. Это не хак с оглядкой на десктопы, а предназначенная для мобильных методика, при которой весь процесс прицеливания, выделения и действий с буфером обмена можно выполнять одним простым плавным действием. (Демонстрацию см. в видео ниже.)
Анимации в игровом стиле
Мы добавили множество мелких визуальных анимаций, позволяющих пользователям узнавать и понимать, что происходит:
Текстовый курсор «скачет» между местоположениями, а маркер «дрожит» при появлении. Это подчёркивает, что курсор всегда находится на экране. Также это подразумевает, что его всегда можно перетащить.
Кроме того, курсор кратковременно создаёт «рябь» при касании, на короткое время вызывая лупу. Цель здесь заключается в том, чтобы мотивировать пользователей сделать нечто большее, чем просто касание. Мы пытались мотивировать их выполнять перетаскивание.
Когда над словом выполняется усиленное нажатие, мы увеличиваем масштаб выделенного, подчёркивая действие жеста.
Жесты-свайпы меню анимируют выбор в направлении свайпа. Свайп вверх в направлении команды вырезания удаляет выделение вверх. Свайп вниз в направлении команды вставки опускает новое выделение вниз.
Обратная совместимость
Мы приложили усилия к тому, чтобы используемые сегодня действия можно было применять в этой новой модели, потому что хотели помочь пользователям. Например, мы сделали так , чтобы касание и перетаскивание, ВСЕГДА перетаскивающие курсор, не работали для текстовых полей с вертикальной прокруткой. Мы выполняем простую проверку — если при начале перетаскивания его первые несколько пикселей были вертикальными, мы выполняем стандартную вертикальную прокрутку текстового поля. Все остальные перетаскивания просто размещают и перетаскивают курсор. Эта система работает достаточно неплохо.
Но хватит текста, вот небольшое демо, объясняющее всё это гораздо лучше:
Внедрение системы
К сожалению, внедрение системы наподобие Eloquent будет сложной задачей. Во-первых, слишком многие ошибочно считают задачу редактирования текста на мобильных «решённой», у них нет мотивации что-то улучшать. Во-вторых, за десяток с лишним лет пользователи привыкли иметь дело со старой, подверженной ошибкам системой. Сложно будет убедить их привыкать к новому.
Но самое важное в том, что устранение проблем редактирования текста не кажется достаточно важным в войне между Android и iOS. Это не та привлекательная функция, которая способна повысить индекс потребительской лояльности. Мне кажется ироничным, что настолько фундаментальное изменение, как улучшение редактирования текста может существенно повысить удобство пользования телефоном и стать причиной смены платформы, но изменения будут медленными и потребуют нескольких лет упорного труда. Android просто не думает в эту сторону. Apple, возможно, подумает.
И это печально, ведь я бы хотел, чтобы мобильные развивались и становились ещё более продуктивными, чем десктопы сегодня. Но судя по выбранному пути, мы будем редактировать так же в течение не менее двадцати следующих лет. Действительно ли мы этого хотим? Жаль, что ужасное редактирование текста — это невидимая проблема, которой никто не отдаёт должного.
