Когда вы пишете компьютерные программы, ошибки неизбежно появляются даже у самых опытных разработчиков. Чтобы устранить ошибку, первым шагом часто является чтение сообщения об ошибке, которое отображается в консоли. Но исследования показывают, что программисты, особенно новички, изо всех сил стараются разобраться в сообщениях об ошибках, не говоря уже о том, чтобы что-то предпринять.
По общему признанию, когда дело доходит до того, чтобы помочь вам, разработчику, восстановиться после ошибок, Flutter не справился с задачей. Консольный вывод ошибки обычно подробный, и часто неясно, как можно отследить ошибку до определенного места в вашем коде. В последнее время мы работаем над решением обеих проблем. В этом посте я собираюсь представить нашу первую попытку увеличить отношение сигнал / шум сообщений об ошибках времени выполнения Flutter и опишу исследования, которые мы провели, чтобы прийти к текущему решению.
Представляем структурированные сообщения об ошибках
В последней версии плагина Flutter для IntelliJ / Android Studio и расширения для VS Code мы добавили новую функцию, которая отображает сообщения об ошибках в расширенном, но кратком формате. Консоль ведения журнала теперь может отображать сообщения об ошибках со следующими улучшениями:
- Выделение сводки ошибки красным цветом
- Добавление пробелов между разделами, чтобы сделать сообщение более читабельным
- Вызов подсказки в сообщении, если таковой имеется, для устранения ошибки
- Сворачивание длинных списков и деревьев в сообщении
На следующем снимке экрана показаны эти четыре улучшения, отмеченные синими кружками, в сообщении, созданном из-за ошибки переполнения макета:
Обратите внимание, что все умещается на одном экране, что позволяет сразу получить общее представление о проблеме. Снижение шума выполняется без удаления какой-либо информации, которая может быть полезна в случаях, когда для исправления ошибки важны более подробные сведения.
Напротив, исходное сообщение об ошибке намного плотнее и не имеет структуры, поэтому трудно найти информацию, которая объясняет, как исправить ошибку. См. Следующий снимок экрана.
На данный момент мы реорганизовали около 85% сообщений об ошибках во фреймворке Flutter, чтобы воспользоваться преимуществами этой новой презентации. Со временем в остальные сообщения об ошибках будут внесены улучшения. Мы также планируем улучшить общее представление сообщений об ошибках на основе отзывов пользователей.
Как мы здесь оказались?
Удобство использования сообщений об ошибках - это многогранная проблема. Содержание, структура и представление сообщения об ошибке помогают вам понять его смысл и исправить ошибку. Мы знаем, что сообщения об ошибках во Flutter обычно содержат полезный контент, но его полезность подрывается огромным объемом информации, которую вам приходилось просеивать.
В качестве примера рассмотрим ошибку Виджет с материалами не найден. Эта ошибка возникает, когда виджет ожидает виджет Material в своем дереве предков, но он не найден. Сообщение об этой ошибке было настолько сложно понять, что пользователь обратился за помощью в StackOverflow. В принятом ответе указывается, что ключевая информация уже содержится в сообщении, но пользователь либо не может найти нужную информацию, либо не понимает ее. Никакой новой информации предоставлено не было.
Новый способ представления сообщений об ошибках
Вопрос, опубликованный на StackOverflow, показателен. Это показывает, что не вся информация в сообщении об ошибке одинакова. Этот вопрос также побудил нас задуматься о том, как сделать полезную информацию более заметной, что означает сокращение визуального беспорядка. Применяя теории визуального восприятия и техники в UX-дизайне, мы придумали три варианта сообщения об ошибке: цвета, пробелы и эллипсы.
Чтобы создать вариант цвета, мы проанализировали относительную важность различных фрагментов информации в сообщении и придумали простую схему цветового кодирования:
- Отобразите однострочную сводку ошибки красным цветом.
- Отобразите объект, с которым связана ошибка, синим цветом.
- Отобразите детали, которые обычно не нужны, серым.
Следующий вариант называется пробелами. Мы добавили пробел в сообщение об ошибке, чтобы разделить его на разделы. Мы также добавили заголовки разделов, такие как «Объяснение» и «Возможное исправление», чтобы упростить просмотр сообщения.
Наконец, вариант с многоточием применяет технику прогрессивного раскрытия в представлении сообщений об ошибках и использует возможности современной IDE. Например, мы свернули список параметров виджета TextField и предков виджета после отображения первых трех. Чтобы увидеть остальную часть списка, просто щелкните многоточие после последнего параметра или предка. Получающееся в результате сообщение об ошибке значительно короче оригинала, что увеличивает вероятность того, что ваше внимание сразу привлечет внимание к элементам более высокого уровня в сообщении.
У нас были веские основания полагать, что эти варианты помогут пользователю, но мы не были уверены, сможем ли мы оправдать затраты на их реализацию. Чтобы сделать эти презентации реальными, нам нужно было заставить фреймворк Flutter отправлять структурированные данные об ошибках в IDE, чтобы IDE могла соответствующим образом стилизовать различные части (например, сводку, детали и подсказки) и сворачивать менее важную информацию. Мы спросили себя, стоит ли потенциальное улучшение взаимодействия с разработчиками усилий по рефакторингу API ошибок Flutter и сотен ошибок, которые уже были написаны. Итак, мы решили провести эксперимент, чтобы выяснить, насколько важны структурированные сообщения об ошибках.
Эксперимент
Чтобы сравнить удобство использования трех вариантов с исходным сообщением, мы провели онлайн-эксперимент с использованием анкеты на основе сценария. Мы набрали 52 пользователя Flutter, которых случайным образом распределили в одну из четырех экспериментальных групп. Исходное сообщение об ошибке было показано контрольной группе, а варианты были показаны трем экспериментальным группам соответственно. Участников попросили описать, что было не так, и как они могли бы исправить ошибку за очень ограниченное время. Подробный план исследования можно найти в рецензируемой статье, которую мы опубликовали ранее в этом году на CHI 2019.
Результаты нас очень положительно удивили. Понимание участниками сообщения об ошибке было значительно лучше в любой из трех экспериментальных групп, чем в контрольной группе. Другими словами, доля участников, правильно понявших ошибку в отведенные сроки, была намного выше, когда использовался любой из вариантов, а не оригинал. На следующей диаграмме показано, что вариант с пробелами превосходит исходное форматирование сообщения примерно на 38 процентных пунктов, когда участникам было дано в общей сложности 45 секунд, чтобы прочитать сообщение об ошибке.
Точно так же все варианты сообщения об ошибке превосходили исходное представление сообщения, когда дело доходило до поиска решения.
Когда участников попросили сравнить исходное сообщение об ошибке и вариант, который они использовали в эксперименте, они объяснили, почему им больше понравились варианты. Ниже приведены некоторые примеры. (Слова в скобках добавлены автором статьи.)
«Ошибка справа (вариант« цвета ») - огромное улучшение: критическое короткое сообщение выделено красным, а виджет - синим».
«Скрытие всего объекта Widget уменьшает беспорядок (в варианте« эллипсов »), упрощает поиск причины ошибки».
«B (вариант с пробелами) гораздо проще разбирать. Разделы четко разделены, поэтому при беглом просмотре легко узнать, куда перейти дальше ».
Получив убедительные доказательства из эксперимента, мы решили инвестировать в структурированные сообщения об ошибках. Это был долгий путь, но мы рады, что API исправленных ошибок теперь обеспечивает прочную основу для будущих инноваций, помогая разработчикам исправлять ошибки в своих проектах Flutter.
Что ждет сообщения об ошибках в будущем?
Для ошибок, вызванных кодом пользовательского интерфейса, мы могли бы встраивать диаграммы, анимацию и даже интерактивные деревья виджетов в сообщение, чтобы максимизировать их объяснительную силу. Мы планируем начать некоторые из наиболее амбициозных экспериментов с консолью Dart DevTools, потому что мы не ограничены расширяемостью IntelliJ и VS Code.
Как вы можете помочь нам стать лучше?
Не все ошибки Flutter были переработаны, чтобы в полной мере использовать преимущества этой новой структурированной презентации. В первую очередь мы работаем над ошибками, которые затрагивают большинство пользователей Flutter. Вы можете помочь, сообщив нам, какие сообщения об ошибках могут быть более полезными с помощью нашего трекера проблем GitHub, или вы можете предложить идеи по улучшению представления ошибок в IntelliJ или VS Code.
Подтверждение
Бывший стажер UX Research из команды Flutter Kandarp Khandwala внес существенный вклад в исследование, описанное в этой статье. Мы также благодарим всех пользователей Flutter, принявших участие в эксперименте.
