画像と写真 · ブラウザー画像 & 描画エディター
バグレポートのスクリーンショットに注釈を付けて開発者が対応できるようにする方法
· なぜそれが重要なのか
画像編集 キャンバス ブラウザ処理
透明なボックス、1 つの矢印、短いキャプションを含むスクリーンショットを使用すると、一連の質問を省くことができます。むき出しのスクリーンショットが彼らを誘います。この投稿では、小さな注釈規則を説明し、それをブラウザー エディターで適用する方法を示します。
3 つの明確な質問を生成したスクリーンショット — 「添付資料を参照」がバグ レポートではない理由
役に立つバグのスクリーンショットは、読者が尋ねる前に最初の質問に答えます。 「添付ファイルを参照」というラベルが付いたベア キャプチャでは、開発者は欠陥、影響を受けるコントロール、および期待される結果を検索する必要があります。編集者の小さな視覚的語彙は、そのあいまいさを軽減するのに十分です。関連する領域をトリミングし、問題の周囲に四角形を描き、注意を向けるために線を使用し、簡潔なキャプションを追加します。
画像をレポート全体としてではなく、証拠として扱います。テキストはすぐにピクセルになるため、エクスポートする前にキャプションを書き、スキャンできる程度に短くしてください。キャプチャされたフレームには表示されないインタラクションや状態を説明できるマークがないため、再現手順、ログ、および予想される動作は依然として画像の横にあります。
画像ごとに 1 つの問題 — 関連する領域をトリミングするため、読者が最初に欠陥に気づくことになります
画像ごとに 1 つの問題が読者に明確な視覚的ターゲットを提供します。必要なコンテキストを確立しない限り、関連のないパネル、ブラウザーのクロム、および隣接するコントロールを切り取ります。タイトにトリミングすると欠陥が最初に目に入りますが、フレームがわずかに広いと、壊れたコントロールと周囲のレイアウトとの関係が維持されます。
問題を再現するために必要な手がかりがレポートによって誤って削除されないように、エクスポートする前に切り抜きをオリジナルと比較してください。ハイコントラストのマークは、明るいインターフェイス領域と暗いインターフェイス領域の両方に対して目立つようにし、スクリーンショットは、手順、ログ、および予期される動作を置き換えるのではなく、補足する必要があります。
意味のある図形: ボックス、矢印、キャプション - 各マークが何を意味し、それぞれをいつ使用するかについての最小限の規則
各マークは 1 つのジョブを実行する必要があります。長方形は影響を受けるコントロールまたは領域を分離し、線はギャップまたは位置ずれに目を向け、キャプションは予想と実際の違いを説明します。このエディタでは、四角形、線、およびテキスト マークが提供されます。矢印プリミティブがないため、無地の線が曖昧に読める場合はキャプションに方向を記述してください。
読者が装飾的な選択肢を解読する必要がないように、チーム全体で規則を安定させてください。テキストは配置時に画像にラスタライズされ、別個のオブジェクトとして再編集することはできないため、書き出す前に文言と位置を確認する価値があります。画像は依然として証拠を裏付けるものであり、報告書の行動の詳細に代わるものではありません。
意味のある図形: 長方形、線、キャプション。このエディタには矢印ツールがありません
色と重さはコミュニケーション上の選択であり、装飾ではありません。薄い赤いストロークは、暗いインターフェイスに対して消えたり、画像が縮小されると読みにくくなることがあります。明確なコントラストのある色を選択し、エクスポートに耐えられる十分な幅を長方形に与え、識別する UI の詳細の上に直接線を配置しないようにします。
開発者が実際に課題トラッカーで表示するサイズで完成イメージを確認します。コントラストは明るい領域と暗い領域の両方に残存する必要がありますが、キャプションは欠陥を隠すことなく読み取れる状態を維持する必要があります。サポート レポートには再現手順とログがまだ必要です。視覚的な強調は証拠を示すことはできますが、欠落している動作を補うことはできません。
予想と実際 — 画像自体に、何が起こるべきかを説明する短いキャプションを追加します
予想される文言と実際の文言を区別すると、強調表示された欠陥が小さなクレームに変わります。 「予想: ボタンは入力と一致しています。実際: ボタンは 12 px の位置にあります」は、色付きのボックスだけを表示するよりも読者に指示を与えます。エクスポートされた画像は推測的な診断の段落になるのではなく、目に見える不一致を明確にする必要があるため、キャプションは事実に基づいた簡潔なものにしてください。
コントロールやギャップを覆わずに、マークされた領域の近くにテキストを配置します。エディターは配置時にテキストをラスタライズするため、後でテキスト オブジェクトを編集するのではなく、エクスポートする前に文言と位置を修正してください。再現ステップとログには、1 つの静的フレームからは確立できない詳細が含まれている必要があります。
作業例: 位置がずれているボタン — 要素を切り抜き、ボックスで囲み、隙間に矢印を付け、予想される位置にキャプションを付けます
正しく配置されていないボタンを例として取り上げます。ボタンとその隣接する配置参照が表示されるようにしっかりとトリミングし、コントロールの周囲に四角形を描き、目に見える隙間を示すために線を使用します。エディターには矢印ツールがないため、線で位置を特定し、ボタンを配置する場所を短いキャプションで示します。
「予想: フィールドと一致、実際: 下にシフト」などのキャプションにより、原因を診断するふりをすることなく視覚的な比較が明確になります。ストロークのコントラストとテキストの配置を検査し、マークされたラスターをエクスポートします。再現パス、ブラウザの詳細、ログをチケットに追加して、スクリーンショットがレポート全体ではなく強力な証拠の 1 つとして残るようにします。
作業例: ボックス、ポインティング ライン、キャプションでマークされた、位置がずれているボタン
マークされたスクリーンショットには、一連のクリック、タイミング競合、コンソール例外、ネットワーク応答、またはリロード後にのみ表示される状態を表示することはできません。動きが重要な場合は画面録画に代わるものではなく、再現ステップやログの代わりにはなりません。画像は、事件全体を封じ込めたかのように見せるのではなく、調査の範囲を狭める必要があります。
これらの境界はチケット内に表示されたままにしておきます。環境、期待される結果、実際の結果、手順、関連する診断を作物と一緒に含めます。四角形、線、テキスト マークを使用すると、視覚的な欠陥を見つけやすくなります。レポートの残りの部分では、問題を再発させる方法と、スクリーンショットでは確認できない内容について説明します。
要点: マークが減り、レポートが明確になります — ブラウザ画像および描画エディターのトリミング、注釈、描画ツールがフォローアップの必要のないスクリーンショットをどのように生成するか
通常、マークが少ないほど、レポートがより明確になります。欠陥をトリミングし、1 つの長方形を描き、方向が重要な部分に線を使用し、予想と実際の違いを示す短いキャプションを追加します。ブラウザ画像および描画エディタは、矢印プリミティブや完全なバグレポート システムを要求することなく、ラスター編集としてこれらのトリミング、線、形状、およびテキスト機能を提供します。
閲覧者の想定されるサイズでコントラスト、配置、文言を確認した後でのみエクスポートしてください。次に、イメージを再現手順、ログ、環境の詳細と組み合わせます。実装されたツールを使用すると、重要なピクセルを明確にすることができます。開発者が欠陥を再現して修正できるようにするための動作証拠の必要性を取り除くことはできません。