メールの作成時にメールの件名が本文の前に表示されるのはなぜですか？
注：私は読書体験について話しているのではなく、メールを作成する体験に焦点を当てています。
この問題は常に私に発生するため、私はこの問題を非常に認識しています。また、他のすべての人に発生することは間違いありません。メールを入力するたびに、SubjectフィールドがBodyフィールドの前に表示されます。これにより、最初にメールを要約する適切な件名を考える必要があり、常にコンテキストを壊します。次は何が起こる？これが私のいくつかの一般的な観察です：
- イライラしたり、緊急のメールを送信したりする場合は、件名にurgent、important、[〜＃〜] fyi [〜＃〜]そして何をしない！
- 本文にスキップしてメールを書き、最後に件名を理解して記入します。
- 件名なしでメールを送信し、[OK]をさらにクリックして、件名を忘れたことを警告するメールクライアントの苦情ダイアログを削除します。
- （私と最も一般的）件名に完全な文を書き、本文を書き、戻って件名が良くないことに気づき、送信する前に件名を変更します。
- 1行のメールの場合は、本文なしで件名に入れます。 FTW！
これが私の質問/苦情です（そしておそらくこのUXで修正が提案されています）：私の10年間のコンピューター使用で、なぜ電子メールの本文の後に件名フィールドを置くことを誰も考えなかったのですか？私が見逃しているものはありますか、それとも書き留めた後で頭に何かの要約があるのは自然ではありませんか？
手紙を郵送した場合、手紙を書く前に封筒に件名はありません。
メッセージの本文フィールドの後に件名フィールドを置くのは正しいでしょうか？いいえの場合、なぜですか？
編集5/25/2013 07:74 PMこれが私が非常に基本的だと思うもののインターフェースです composeのプロトタイプUI 。同じURLに編集内容を保存し、投稿を続けてください。
追伸これをすべて書いた後で、この投稿の件名を変更しました。
編集5/25/2013 11:42 AMだから文句を言うのではなく、プロトタイプをさらに一歩進めて、電話で試してみました！ CSSの労力が少ないため、見た目はフラットに保たれます。
メールは、チャットタイプのメッセージングの形式を意図したものではありませんでした。これらは電子版のメールであることを忘れないでください。そのため、それらをメールの目的に合わせて変更しようとするのは間違いです。
最初に件名を書く理由について：
- 件名は電子メールのヘッダーの一部です（元の RFC822 および新しい RFC5322 を参照）。初期の電子メールシステム以降本文の前にヘッダーを表示しました。本文の前にもヘッダーを書き込むことで一貫性を保つことが理にかなっています。
- 論理的な流れは、メールを書く前にその内容について考えます。そのため、メッセージの本文の前に件名を付けることは理にかなっています。
元の理由はさておき、件名の前に本文があるとしたら、多くのUX問題に遭遇し、それからほとんど利益を得られないでしょう。 動作することが証明されているものと、人々が慣れているものに注意してください。
チャットタイプのメッセージングに電子メールを使用するプログラムを作成する場合は、件名フィールドは不要なので、いつでも完全に省略できます。ただし、それをオプションにすることもできます。使用できる場合は、ボディの前に配置します。
読者のために：あなたはものがすべてについて何であるかを知る必要があります。
ライターの場合：何について書こうとしているのかを知る必要があります。
これは質問に似ているかもしれません ATMがカードの前に現金を渡さないのはなぜですか？ ：
ユーザーはタスクを順番に実行しますが、目標を達成するとタスクは完了したと見なします。補助的なステップは、この時点で簡単に中止できます。
メールを書く目的は情報を伝えることです。メッセージの本文が完了すると、その目標はおそらく達成され、件名の追加は単に便利です（後で受信者との両方にとって）そのメールをすばやくすばやく見つけるために）-したがって、ユーザーは本文の後に件名を入力せずに送信を押す可能性が高く、その逆も同様です。
一方、メッセージ本文の下に「to」フィールドを置くと、実際にはかなりいい音がします。通常の手紙では、（-====）後にエンベロープにアドレスを書き込みます後手紙自体を書いて、不完全なメッセージが意図した受信者に届くことも防ぎます。通常の実装で私が目にする唯一の利点は、受信者のアドレスを実際に知っていることを確認する必要があることです。彼らはメールをドロップし、直接問題について話し合うことができます...
この質問には、他の回答とは少し異なる視点からアプローチしたいと思います。
注文内容
提起された本質的な質問は、フォームフィールドを注文する哲学と方法論を問うことです。
一方では、著者がそれらを書くことが期待される順序でそれらを注文したいと思うかもしれません。これは、フォームがどのようにレイアウトされるかを示す、完全に実用的なメンタルモデルです。これを作成者中心のレイアウト、または意識の流れの順序と呼ぶかもしれません。
ただし、これはフォームがオンラインまたはオフラインでレイアウトされる方法ではなく、実際に公開されているファイル形式や転送プロトコルとはまったく関係がないという文化的な現実です。
初めに官僚制がありました
そして紙は官僚制であり、
そして紙は官僚制でした。
ある時点で、誰かがフォームフィールドをレイアウトする順序を決定する必要があり、2つの一般的な並べ替え順序が機能します（プロのプリンタとしての以前の経験に基づいて-フォームのコピー、変更、およびデザインに何時間も費やしました）。
重要度の緊急順で並べ替え、処理順序で並べ替え
我慢できないほど多くの例が必要な場合は、 IRS Forms and Publications にアクセスしてください。
いずれの場合も、標準のフォームの順序は次のようになります。
- 暗黙のうちに、このフォームは誰のためのものか。政府の設定では、IRSフォームはIRS用であり、法的書類は裁判所用などであるため、これは明白に省略されています。
- これについては何ですか-フォーム番号、タイトルなど.
- 知っておくべきことを教えてください-あなたの情報、苦情、「メッセージ本文」などがここに表示されます。
- ここにサイン-または「あなたが再びいることを教えてください-今回は、気持ちを込めて！」
一般に、フォームの目的は、分類、標準化、完全性などを含む一連のデータに順序を課すことです。これは一般的に、不十分な情報を提供するか、処理に時間がかかり、応答時間が遅くなり、関係者全員により多くの仕事をさせる手紙として、全員の利益のためです。
著者中心性
コンピュータの出現により、記入後のフォームの使用方法に依存しない方法でフォームを提示することが可能になりました。本発明は、主に自動入力フィールドと非表示フォームフィールドに適用されています（たとえば、電子メールプロトコルがその情報を必要とする場合でも、電子メールクライアントで「from」に入力する必要はありません）。
ただし、フィールドの順序は、印刷されたフォームとほとんど変わっていません。ここでの一般的な質問は「なぜ違うのか」です。ここでは、ユーザーの期待に違反する必要があります。これは、明確で人気があり、説得力のある理由がある場合にのみ行う必要があります。
タイトルを付けるかどうか
「主題」と「タイトル」の概念は、非常に特殊な文化的構成要素です。実際、一部の文化や文脈では、タイトルは完全に省略されています。たとえば、 Jalālad-DīnMuhammadRūmī の作品では、コールマンバークス（人気の翻訳者）が通常、特定の詩にタイトルを追加しますが、タイトルは完全に彼のものです。 13世紀のペルシャでは、詩人は、巻/本/原稿のコンテキスト内でそれ自体に十分な詩と見なし、特定の詩を参照する場合、最初の数語または行がタグとしてよく使用されました。
しかし、現代の西洋文化では、この習慣は前代未聞です-書かれた作品のタイトルには特別な意味があり、特に重要であると考えられています。タイトル（または件名）の重要性はこれまでに拡張されており、「インスタントメッセージ」、社会的ステータスの更新、またはツイートよりも重要度の高い定期的な書面による通信は、独自のタイトルを持っています。えっと、新しい章がなくては、本の10ページを読み通すことはほとんどできませんが、章自体にはタイトル、サブタイトル、章の間に十数の小見出しがあることがよくあります。
最初に来たもの：主題、または体
書面の作品については、クイックメールであれ、リバイアサン原稿であれ、ミミッシブの本文、それが扱う主題、および理想的なタイトルまたは短い要約との関係は、普遍的でも単方向でもありません。
この現実が「ワーキングタイトル」というコンセプトを生み出しました。そして、どれが最初に来るかは、人、気分、トピックによって異なります。誰かが誕生日おめでとうことを望んでいることを知っているかもしれません。そのため、電子メールの件名はかなり明白であり、最初に書かれます。会議の発表、決算報告の発表なども同様です。
しかし、時には、何を言う必要があるか、誰に言うべきかさえわからないうちに、何かを言う必要があることを知っている場合があります。そのため、フォームへの入力を厳密に強制する必要はありません。これは、人々が電子メールを使用する方法の現実を単純に反映しているためです。
他のフォームでは、誰かが特定の情報を調べて入力し、他の情報が見つかったときに戻って他のフィールドに入力することも予想されます。繰り返しになりますが、想定されるデータの可用性に基づいてフォームを並べ替えるのは、せいぜい面倒で混乱を招くだけです。
優れたユーザーエクスペリエンスデザイナーとは
全員が異なる予測不可能な順序でフォームに入力する場合、フィールドはどの順序で配置する必要がありますか？さて、デジタルフォームのような電子メールプログラムでは、古い標準の注文システムを使用して、既存のユーザーの期待に応えます。最高のユーザーエクスペリエンスを提供するには、宛先、件名、およびメッセージが他の順序で入力されない個別のトランザクションであることを主張するマルチステップウィザードを作成するなど、特定の順序を強制しようとしないでください。
もう1つの質問は、OPの場合、最初に本文に記入し、件名を完全にスキップすることを好む場合の欠点は何ですか？まあ、余分なボタンを押す（タブ）、またはマウスをクリックします。誰かが最初に件名を入力しないとびっくりするようなフォーム検証の愚かな使い方がなければ、問題はないはずです-1つのフォームですべてを不快にしてください。そうそう、人間は本当にフォームを憎むことを忘れないでください。彼らはただします。そのため、一般的なフォームでは、物事を移動して、とにかく避けたい日常のタスクについて考えさせるよりも、人々をすぐに悩ませる方法はほとんどありません。
件名を編集または追加するために上または下にスクロールする必要があることに関して、多くの（ほとんど？）メールクライアントは、本文自体がドキュメントの上部に、宛先、CC、BCC、および件名がすべて添付されているシステムに移動しています。独自のスクロールバーがあるので、受信者と件名の追加/削除/編集はクリックするだけです。どうして？ねえ、時々あなたは話し終えた後まで何を話しているのかわからない、またはあなたは念のため上司にCCをした方がいいことに気づくからです。
（13世紀のペルシャの電子メールクライアントに関するスピリチュアルな詩を参照していますか？はい、私はそこに行きました。それが私のやり方です。）
読者として、「なぜこのメールを送ってくれるのですか？」だから、私がto-doリストにある他の重要なことすべてを行う代わりに、今読んでいる間、それが私の価値があるかどうかを知っています。
読者として、私はライターが私にメールを送信する理由を知っていることを期待します。そして、要点は、意識の流れを大きな白に捨て始める前に、なぜ私にメールを送信するのかを知ってほしいと思いますスペース。
彼らが私の読書に時間を費やすことを望んでいるなら、彼らが書こうとしている何かが私にとってまったく価値があるかどうか、または私が時間を無駄にするかどうかを検討するために最初に立ち止まることを彼らが私に礼儀正しくしてくれたことを願っていますそれを読んで。
著者として、「「メッセージ作成」ボタンをクリックするきっかけとなった理由」を考えてください。たとえば、コンテンツの場合は、「電話チャット後の考え」で十分だと思います。なぜ私にメッセージを送っているのかわからない場合は、なぜそれを読む必要があるのかわかりません！
開発者として、私はしたいです 力 私にメールを送ろうと思っている人になぜについて考えるように勧めます前彼らは実際にキーボードのキーを叩き始めます。
シンプルな情報階層です。論文の上部に著者とタイトルがあるように、メールも同じです。
さて、それは作者ではなく読者にとってのみ重要であると主張することができます。そして、それは妥当な議論だと思います。とは言っても、電子メールを読むとき、それらには特定の階層があり、同様に有効な引数は、電子メールの作成に使用されるテンプレートは、それを読む方法と一致する必要があるということです。
結局のところ、本文の上に件名を表示しても、ユーザーが最初に入力する必要はありません。したがって、それはユーザビリティの主要な問題ではない可能性があります。それはまた、目に見える領域に合わせるのがとても簡単な小さな情報行です（体の下に置くと混乱を招く可能性があります）
私はこれについて2つの特定の正当化を考えることができます：
これが標準の慣例ではなかった頃は、件名と本文の間に大きな違いはなかったはずです（テキストメッセージングの初期の頃、さらにはTwitterについても考えてみてください）。メールに多くのものを追加する機能と便利さを考えると、イベントの自然な流れの1つは、人々ができる限り多くを追加することです。残念なことに、これは人々が今、件名（たとえば、営業やマーケティングの人々）と本文（たとえば、一般的なオフィスチェーンメール）の使用を乱用していることを意味します。
読者が情報を見るのと同じ方法で著者の入力を構成することは役立ちます。要約（つまり、件名）が次の場合、詳細を知りたい人のために情報を段階的に公開するという原則はより効果的です。本文の前に配置されます。もちろん、これは作成者にとってよりユーザーフレンドリーであるかどうかを正当化するものではありませんが、情報を入力する別の方法を誰も提供していないことを考えると、何も行われていません。
すべてのユーザビリティの問題と同様に、最善の方法はそれを試して何が起こるかを確認することです。別の方法で入力を受け入れるWebページを表示する場合は、リンクを提供してください！
他の人が電子メールアプリケーションをそのように記述していて、誰もがそれに慣れているため、人々はこの方法で電子メールアプリケーションを記述しているのではないかと思います。ユーザーは、まったくなじみのない電子メールアプリケーションに直面したときに、エントリフォームの上部に件名を、下部に本文を入力するよう求めます。ユーザーは期待どおりのものを手に入れ、それが異なるパラレルワールドについては考えません。ソフトウェアが彼らの期待と一致しないならば、ユーザーはさえ苛立たせるでしょう。 （「Sheesh、どこに件名を入れればいいのでしょうか？」）したがって、電子メールを作成するためのユーザーエクスペリエンスの変更は、ユーザーの期待との「後方互換性」のために非常に注意深く設計する必要があります。
良いアイデアは、うまく実行された場合、ユーザーの最終的な承認を条件として、メッセージ本文の光沢から自動的に件名を生成するためのチェックボックスである可能性があります。または、3つの異なる件名から選択することもできます。これは、ユーザーが入力した場合、ユーザー自身の件名の改善を示唆することもできます。
このメッセージの場合、
"me"は"you"よりもわかりやすい件名になる場合があります。[Accept][Reject]。」
:)
それは本当に重要ではありません。
Google Mailをご覧ください。
件名フィールドに戻るのは簡単です。フィールド内をクリックするか、Shift-Tabを押します。
そして、なぜGoogle Mailは件名フィールドを本文の上に置いたのですか？他の誰もがそれをしているからです。他の人はすでに理由を説明しています。件名は、本文テキストの前にあるヘッダーです（ RFC822 を参照）。または、このシーケンスにより、ユーザーは伝えたいことを考える必要があります。等々。また、ステップの順序によってユーザーがタスクを実行する方法が変わることは事実です。
しかし、これは重要ではありません。
元に戻るのは簡単なので、[件名]フィールドをスキップして本文から始めることがよくあります。
ここには2つの視点があります。あなたは（作家の）視点について話していて、適切なタイトルを考えることは少し厳しいように見えますが、読者の視点を見るとき、彼が大陸の前に最初に見出し（電子メールのタイトル）を読むことは完全に理にかなっています。
あなたの文脈では、メッセージとしてメッセージを使用しているように見え、タイトルを使用するという考えはあまり意味がないように思われますが、それでも「電子メールメッセージ」に件名を含めることは厄介ではありません。
使いやすさの点では、これは問題ないと思いますが、これはあなたの個人的な好みとは異なる場合があります。インターフェイスのパーソナライズは、さらに使いやすさの上の別のレイヤーです。
印刷されたメディアを介して通信しているときはいつでも、タイトル/ヘッダーを含めることは、書かれていない種類の規範です。ヘッダーの機能は、次の内容を（1行で）要約することです。新聞、雑誌、ポスター、プレゼンテーションなどでご覧いただけます。
タイトルのない雑誌やニュース記事を想像してみてください。 読みたいものをどうやって決めるのですか？何百通もの電子メールを受け取る人は、電子メールを読まないでフィルタリングする何らかの方法が必要です。タイトルは、これを行うための優れたメカニズムを提供します。最初にコミュニケーションの要点を理解し、それから詳細について話し合います。
あなたが手紙にヘッダーを含めることのポイント;はい、特に、求人応募などの正式な手紙でそれを行います。
メール作成時のヘッダー入力ボックスの配置について。ヘッダーを本文の下に移動することを検討することは、悪い考えではないかもしれません。ただし、前述の理由により、受信者にとってヘッダーは上部にある必要があります。
もう1つ考えました。それは、キーボードの使い方に関係しています。
私はいつもフォームのフィールド間をタブで移動します。ただし、本文に入ると、Tabキーはキャプチャされるはずなので、タブ文字をインデントとして入力できます。
サブジェクトがタブオーダーでボディの後に来る場合、マウスに切り替えるか、なんらかの修飾キーを使用しないと、実際にサブジェクトに到達できません。
通常の流れでは、それはかなり破壊的です。
これはタスクのパフォーマンスの問題です。人々はどのように電子メールを書きますか？インターフェイスはタスクのパフォーマンスをサポートする必要があります。
トップダウン：最初に対象が身体に影響を与える
ボトムアップ：身体が最初に影響を与える
どちらのプロセスも機能しており、どのアプローチをいつ使用するかはコンテキストによって決まります。したがって、タスクのすべてのポイントで、何もしないか、件名（および他のフィールド）を入力/編集するための苦労のない機会を提供することにより、どちらのフローも壊さずに両方のアプローチをサポートします。