Государственное управление - ваш союзник
TL;DR;
Реализуя простой конечный автомат, можно улучшить взаимодействие с пользователем [UX] в качестве фронтендера, поскольку он охватывает три возможности, с которыми всегда сталкивается пользователь: ожидание завершения загрузки, обработка ошибок и нормальный поток наши приложения.
ОБНОВЛЕНИЯ
* 2018, 27 сентября: мой друг напомнил мне, что цикл, происходящий на изображении выше, в некоторой степени также происходит в серверной части. Если вы примените его при разработке интерфейсов, уровень ваших API-интерфейсов повысится.
* 2019 17 мая: добавлено немного о стабильных и быстрых API-интерфейсах, когда речь идет об оптимистичном пользовательском интерфейсе, небольших исправлениях и комментариях о Schrödinger
* 2020 2 ноября: исправьте опечатки и добавьте ссылку для саморекламы.
Используйте конечный автомат для реакции на пользовательские (и системные) события
Когда пользователь входит в ваше приложение, он запускает событие, которое загружает содержимое приложения в его браузер или активное мобильное представление. Нетехнические пользователи обычно не знают об этом событии, но вы знаете. И часть того, что могут сделать фронтендеры для обеспечения хорошего взаимодействия с пользователем, - это изящная реакция на пользовательские события.
Здесь я представляю не рецепт, а некоторые состояния обычного приложения, о которых нужно помнить при работе с интерфейсом.
Хотя эти состояния могут применяться к приложению и его компонентам по отдельности, я буду придерживаться термина «приложение», и я также буду рассматривать состояние загрузки как начальное - даже для синхронных компонентов мы должны ждать миллисекунды, чтобы использовать, когда вы думаете об этом.
Состояние загрузки
Этот этап зарезервирован для контроля повреждений, в то время как с приложением нельзя взаимодействовать, в мире, где ожидается, что приложения будут очень отзывчивыми (с точки зрения скорости).
Это состояние следует переименовать в «состояние Шредингера», потому что, пока сервер не ответит, запросы находятся в подвешенном состоянии.
Когда приложение слишком долго реагирует на запросы, пользователи склонны думать, что оно зависло, или ошибочно принимают этот этап за этап, зарезервированный для ошибки. Вы хотите избежать обеих ситуаций.
Скорость
Как пользователь я могу сказать, что мы субъективные существа, большинство из нас не будет смотреть на тесты, мы полагаемся на свое чутье и придерживаемся того, которое кажется быстрее, потому что быстрее производит впечатление, что приложение работает.
Я не буду вдаваться в подробности, почему скорость - это название игры при получении данных на этом этапе, а также о том, как ее улучшить. Но вкратце:
Скорость ошибочно принимается за качество с точки зрения пользователя, поэтому они переходят на более быстрые приложения только потому, что существует множество приложений, которые могут не делать то же самое, но все же их будет достаточно. И пользователям некогда тратить время зря.
В этом вам могут помочь кэширующие и автономные приложения, но у них есть свои компромиссы, поэтому выбирайте с умом.
Что показать
Как программист, я не эксперт по UX, поэтому я лучше посоветую вам спросить своего товарища по UX-команде, что показать на этом этапе.
В личных проектах я всегда использую простые сообщения вместо анимации, потому что они могут повлиять на производительность и со временем раздражать.
Что касается веб-приложений, ориентированных на страны третьего мира, или плохого соединения в целом, я видел, как CSS влияет на загрузку страницы и вызывает отток.
Будь оптимистом
Когда пользователи запускают событие, которое изменяет данные, вы можете обмануть их.
Оптимистичный ответ - это демонстрация состояния успеха, пока вы ждете, пока сервер завершится успешно (и пользователи никогда не узнают, что их обманули) или потерпит неудачу, ситуация, когда вы сообщаете им об ошибке (или нет, в зависимости от характера вашего приложения). .
Этот метод не рекомендуется, если ваш API работает медленно или нестабильно, так как это повлияет на переключение контекста пользователя.
Некоторые пользователи могут сопротивляться обману и отказываться от вашей подлости. Чтобы этого избежать, у вас может быть «промежуточное состояние загрузки», которое кажется успешным, но каким-то образом показывает, что действие еще не завершено.
Состояние ошибки
Когда что-то идет не так, вам нужно показать пользователям, что что-то произошло.
TK добавить иллюстрацию, показывающую ошибку / ошибку, вместо того, чтобы использовать эту фразу как мета-шутку
Винить пользователя
Особенно, когда пользователи делают что-то, чего вы не хотите, добавляйте отзывы, чтобы сообщить им, что вы недовольны.
Единственное правило здесь - не прерывать их, поэтому избегайте показа предупреждений с помощью назойливых уведомлений.
Вы также должны разместить отзыв как можно ближе к источнику ошибки.
В эту категорию попадают ввод нежелательных значений
Виноват кодер
Иногда в коде случаются ошибки, и приложение взрывается. Он может буквально перестать работать.
Ваша задача здесь - вернуться в полезное состояние с минимальным ущербом для пользователя и предоставить адекватную обратную связь.
Если вы работаете над критически важным приложением, возможно, стоит прервать пользователей, чтобы они, по крайней мере, были вынуждены признать, что им нужно будет проверить, что вызвало ошибку. Надеюсь, ваш отзыв поможет им в этом.
Винить третьи стороны
В тех случаях, когда ни вы, ни пользователь не сделали что-то неправильно (Интернет не работает, память заполнена и т. Д.), Пользователи должны знать, что их работа не может продолжаться из-за внешних факторов.
Если пользователи обвиняют своего интернет-провайдера до того, как поймут, что ваше приложение - единственное, что не работает, значит, вы сделали потрясающий UX / приложение.
Не подводите их слишком долго, иначе вы их потеряете.
Ошибка разработчика, не исправившего ошибку. Итак, здесь действует то же «правило» уведомления и восстановления от Авторство кодера.
Вы можете просто использовать общее сообщение об ошибке, если не знаете, что остановило вашу программу.
Пожалуйста, подумайте о шутках как о сообщениях об ошибках. Шутить - это искусство, и его использование в неподходящие моменты принесет больше вреда, чем пользы.
С критически важными приложениями просто избегайте этого.
Успешное государство
Это возлюбленная программиста. Зарезервировано на тот момент, когда сервер ответил именно так, как вы ожидали, и пользователь может использовать приложение в обычном режиме, как вы планировали.
Фиксированный контент
Приложение загрузилось правильно, и вы показываете данные, применяя методы UX для улучшения восприятия вашей страницы.
Помните, что способ использования таких данных может привести к тому, что приложение перейдет в состояние ошибки.
Когда данные недоступны, показ значения по умолчанию может быть полезным. Лично я хотел бы подчеркнуть, что значение по умолчанию используется с некоторым стилем.
Много контента
Списки, таблицы, результаты поиска и тому подобное, которые могут быть представлены в виде записей массива, имеют собственное дерево состояний, и мы можем разбить его на 4 состояния.
- Нет элементов: массив пуст, нам нужно поместить сюда заполнитель с соответствующими данными
- Одинокий элемент: в массиве один элемент, мы должны его показать
- Мало элементов: в массиве более одного элемента, пользователи должны иметь возможность различать их.
- Больше элементов, чем вы хотели показать: те же, что и предыдущие, но с пользовательским контролем, чтобы их лучше обслуживать, например пагинация и ленивая загрузка
Внимание - ограниченный ресурс
Если вы дочитали до этого места, я хорошо поработал. Обычно люди обманывают средние формы, потому что там слишком много хорошего контента, но не хватает времени.
Пользователи не сосредотачиваются на вашем приложении все время. Попытки привлечь их внимание движением и изменением цвета взывают к нашим человеческим инстинктам.
Еще одна хорошая практика - показать, с чем могут взаимодействовать пользователи. Вот почему так важны курсоры и выделения.
Ты не постоянный пользователь
Рискуя показаться педантичным, помните, что вы не обычный Алекс, использующий компьютер. Пользователи, как правило, знают только инструменты, с которыми они работают, и знают, как просматривать веб-страницы.
Обычные пользователи используют компьютер, как будто это чужая технология, поэтому, если что-то не работает должным образом, они не будут искать, как это исправить в Google / StackOverflow. Предполагалось, что все должно работать, без раздумий.
Как будто я рассматриваю электричество как разновидность нечестивой магии, которую я могу использовать, но не «отлаживать». Мне не нужно это понимать, потому что я всегда могу нанять кого-нибудь, чтобы разобраться с этим = D
Заключение
Знание этих трех состояний означает, что вы как программист можете улучшить UX и даже обсудить его с людьми, которые работают с ним напрямую.
Поделитесь, пожалуйста, и похлопайте несколько раз, если вам понравилась статья или вы узнали что-то новое.
Как всегда, критика приветствуется.
