Изображения и фотографии · Редактор изображений и рисунков в браузере
Как аннотировать скриншот отчета об ошибке, чтобы разработчики отреагировали на него
· Почему это важно
редактирование изображений холст обработка браузера
Скриншот с прозрачной рамкой, одной стрелкой и короткой подписью избавляет от вопросов; голый скриншот приглашает их. В этом посте изложено небольшое соглашение об аннотациях и показано, как его применить в редакторе браузера.
Скриншот, на котором возникли три уточняющих вопроса: почему «см. прикрепленное сообщение» не является отчетом об ошибке.
Полезный скриншот ошибки отвечает на первый вопрос, прежде чем читатель его задаст. Простой захват с пометкой «см. прикрепленный файл» оставляет разработчику поиск дефекта, затронутого элемента управления и ожидаемого результата. Небольшого визуального словаря редактора достаточно, чтобы уменьшить эту двусмысленность: обрежьте нужную область, нарисуйте прямоугольник вокруг проблемы, используйте линию, чтобы привлечь внимание, и добавьте краткий заголовок.
Относитесь к изображению как к доказательству, а не как к целому отчету. Текст сразу становится пикселями, поэтому перед экспортом напишите заголовок и сделайте его достаточно коротким для сканирования. Шаги воспроизведения, журналы и ожидаемое поведение по-прежнему относятся к изображению, поскольку никакая отметка не может описывать взаимодействия или указывать на то, что захваченный кадр не отображается.
Одна проблема на каждое изображение — обрезка до нужной области, чтобы дефект был первым, что видит читатель.
Одна проблема на изображение дает читателю четкую визуальную цель. Обрезайте несвязанные панели, хром браузера и соседние элементы управления, если они не создают необходимый контекст. Плотное кадрирование делает дефект первым, что бросается в глаза, а немного более широкая рамка может сохранить связь между сломанным элементом управления и окружающим макетом.
Сравните кадрирование с оригиналом перед экспортом, чтобы отчет случайно не удалил подсказку, необходимую для воспроизведения проблемы. Высококонтрастные метки должны выделяться как на светлых, так и на темных участках интерфейса, а снимок экрана должен дополнять, а не заменять шаги, журналы и ожидаемое поведение.
Фигуры со смыслом: прямоугольник, стрелка, подпись — минимальное соглашение о том, что говорит каждый знак и когда его использовать.
Каждая отметка должна нести одно задание. Прямоугольник изолирует затронутый элемент управления или область, линия направляет взгляд на пробел или несовпадение, а подпись объясняет разницу между ожидаемым и фактическим. Этот редактор предлагает прямоугольные, линейные и текстовые метки; у него нет примитива стрелки, поэтому опишите направление в заголовке, когда простая линия может быть прочитана неоднозначно.
Следите за тем, чтобы соглашение было стабильным для всей команды, чтобы читателю не приходилось расшифровывать декоративные варианты. Текст растрируется в изображение при размещении и не может быть повторно отредактирован как отдельный объект, поэтому перед экспортом стоит проверить формулировку и местоположение. Изображение остается подтверждающим доказательством, а не заменой поведенческих подробностей отчета.
Фигуры со смыслом: прямоугольник, линия и подпись; в этом редакторе нет инструмента со стрелками
Цвет и вес — это выбор коммуникации, а не украшения. Тонкая красная линия может исчезнуть на темном интерфейсе или стать трудночитаемой после уменьшения изображения. Выберите цвет с четким контрастом, дайте прямоугольнику достаточную ширину, чтобы его можно было экспортировать, и избегайте размещения линии непосредственно над деталями пользовательского интерфейса, которые она должна идентифицировать.
Проверьте готовое изображение в том размере, который разработчик фактически увидит в системе отслеживания проблем. Контраст должен сохраняться как в светлых, так и в темных областях, а подпись должна оставаться читаемой, не перекрывая дефект. Вспомогательный отчет по-прежнему нуждается в этапах воспроизведения и журналах; визуальный акцент может указывать на доказательства, но не может восполнить недостающее поведение.
Ожидаемое и фактическое — добавление короткой подписи, описывающей то, что должно было произойти, в самом изображении.
Формулировка «ожидание против факта» превращает выделенный дефект в небольшую претензию. «Ожидается: кнопка совмещена с вводом; факт: кнопка расположена на 12 px низко» дает читателю больше направления, чем просто цветной прямоугольник. Сохраняйте эту подпись фактической и компактной, потому что экспортированное изображение должно прояснить видимое несоответствие, а не стать абзацем умозрительного диагноза.
Разместите текст рядом с отмеченной областью, не закрывая элемент управления или пробел. Редактор растрирует текст при размещении, поэтому проверьте формулировку и положение перед экспортом, вместо того чтобы ожидать редактирования текстового объекта позже. Шаги воспроизведения и журналы должны содержать детали, которые невозможно установить по одному статическому кадру.
Проработанный пример: кнопка с перекосом — обрезка, рамка элемента, стрелка к пробелу, подпись с ожидаемым положением
В качестве рабочего примера возьмите смещенную кнопку. Обрежьте достаточно сильно, чтобы показать кнопку и соседнюю с ней ссылку на выравнивание, нарисуйте прямоугольник вокруг элемента управления и используйте линию, чтобы указать на видимый разрыв. Поскольку в редакторе нет инструмента со стрелкой, пусть линия указывает местоположение, а короткая подпись указывает, где должна располагаться кнопка.
Заголовок типа «Ожидаемое: выровнено по полю; фактическое: сдвинуто вниз» делает визуальное сравнение понятным, не претендуя на диагностику причины. Проверьте контрастность штрихов и расположение текста, затем экспортируйте отмеченный растр. Добавьте в заявку путь воспроизведения, сведения о браузере и журналы, чтобы снимок экрана оставался убедительным доказательством, а не всем отчетом.
Рабочий пример: кнопка со смещением, отмеченная рамкой, указывающей линией и надписью.
На отмеченном скриншоте не может быть отображена последовательность кликов, гонка времени, исключение консоли, ответ сети или состояние, которое появляется только после перезагрузки. Он не заменяет запись экрана, когда движение имеет значение, и не может заменять этапы воспроизведения или журналы. Изображение должно сузить расследование, а не претендовать на то, чтобы охватить весь инцидент.
Держите эти границы видимыми в билете. Включите окружающую среду, ожидаемый результат, фактический результат, шаги и соответствующую диагностику вместе с урожаем. Прямоугольник, линия и текстовые метки облегчают обнаружение визуального дефекта, а остальная часть отчета объясняет, как сделать так, чтобы это произошло снова и что не может показать снимок экрана.
Вывод: меньше пометок, более четкий отчет — как инструменты обрезки, аннотаций и рисования в редакторе изображений и рисунков в браузере создают снимок экрана, который не требует дополнительных действий.
Меньшее количество оценок обычно делает отчет более понятным. Обрежьте дефект, нарисуйте один прямоугольник, используйте линию там, где направление имеет значение, и добавьте короткую подпись, обозначающую разницу между ожидаемым и фактическим. Редактор изображений и рисунков в браузере предоставляет возможности обрезки, линий, форм и текста в виде растровых изменений, не требуя при этом примитива стрелки или полноценной системы отчетов об ошибках.
Экспортируйте только после проверки контрастности, размещения и текста в соответствии с вероятным размером зрителя. Затем соедините изображение с этапами воспроизведения, журналами и подробностями среды. Внедренные инструменты могут сделать важные пиксели очевидными; они не могут устранить необходимость в поведенческих доказательствах, которые позволяют разработчикам воспроизводить и исправлять дефект.