Почему тема электронной почты появляется перед телом при составлении электронной почты?

Примечание: Я не говорю о чтении, я сосредоточен на опыте составления электронной почты.

Я очень хорошо знаю эту проблему, так как это происходит со мной все время, и я уверен, что это происходит со всеми остальными. Всякий раз, когда я печатаю электронное письмо, поле Тема появляется перед полем Тело . Это заставляет меня сначала подумать о хорошей теме, которая суммирует электронную почту, всегда нарушая контекст. Что будет дальше? Вот несколько моих общих наблюдений:

  • Если вы расстроены или вы отправляете по электронной почте что-то срочное, вы помещаете тему срочный , важный , FYI , а что нет!
  • Вы перейдете к телу, напишите свой адрес электронной почты, и в самом конце вы выясните тему и заполните ее.
  • Вы отправляете электронное письмо без темы и делаете дополнительный щелчок на OK, чтобы избавиться от диалога с жалобой клиента электронной почты, предупреждая вас о том, что вы забыли тему.
  • (Чаще всего со мной). Вы пишете полное предложение в теме, напишите тело, вернитесь и поймите, что предмет не подходит, и измените тему перед отправкой.
  • Если это однострочное электронное письмо, вы помещаете его в тему без тела! FTW!

Вот мой вопрос /жалоба (и, возможно, предложенное исправление в этом UX): за 10 лет использования компьютера почему никто не думал о том, чтобы поместить тему в поле после тела электронной почты? Есть ли что-то, что мне не хватает, или не естественно, что у вас есть сводка чего-либо в голове после того, как вы ее записали?

Если я отправил письмо, у меня не было бы предмета на конверте, прежде чем писать письмо.

Правильно ли поставить поле subject после поля тела сообщения? Если нет, почему бы и нет?

Редактировать 5/25/2013 07:74 PM  Вот интерфейс для того, что я считаю очень простым прототипом пользовательского интерфейса для составления . Сохраните изменения в одном URL-адресе и продолжайте публикацию.

P.S. Я изменил тему этого сообщения после того, как написал все это.

Редактировать 5/25/2013 11:42 AM  Поэтому вместо того, чтобы жаловаться, я сделал прототип еще на один шаг и попытался сделать его на телефоне! Удерживает внешний вид, так как он требует меньших усилий CSS: P вот как это выглядит прямо сейчас

Концепция iPhone

76 голосов | спросил MaX 23 Mayam13 2013, 10:33:14

13 ответов


54

Электронные письма никогда не были предназначены для обмена сообщениями типа чата . Помните, что это электронные версии почты, поэтому попытка изменить их, чтобы быть тем, для чего они не были предназначены, является ошибкой.

Что касается причин, по которым мы сначала пишем строку темы:

  1. Строка темы является частью заголовка сообщения электронной почты (см. оригинальный RFC822 и новый RFC5322 ), и поскольку ранние системы электронной почты отображали заголовок перед телом , это имело смысл для согласованность, чтобы также написать заголовок перед телом.
  2. Логический поток думает о том, что такое электронная почта, прежде чем писать. И поэтому имеет смысл иметь строку темы перед телом сообщения.

Исходные причины в сторону, если вы должны были иметь тело перед предметом, вы, вероятно, столкнетесь с множеством проблем UX и получите очень мало от него. Следите за тем, что было доказано для работы и к каким людям привыкли.


Если вы хотите создать программу, использующую электронную почту для обмена сообщениями типа чата, вы всегда можете оставить поле объекта полностью, поскольку это не требуется. Тем не менее я бы сделал это необязательным, и если бы он был доступен, я бы получил его перед телом.

ответил JohnGB 23 Mayam13 2013, 11:18:55
45

Для читателей: вам нужно знать, что это за вещи.

Для писателя: вам нужно знать, о чем вы собираетесь писать.

ответил aliibrahim 23 Mayam13 2013, 11:28:27
10

Это может быть похоже на вопрос Почему банкоматы не дают вам наличные деньги перед вашей карточкой? :

  

Пользователи выполняют задачи последовательно, но рассматривают задачу как завершенную, как только они достигли своей цели. Дочерние шаги легко отказаться от этого момента.

Цель письма - передача информации. Как только тело сообщения будет завершено, цель будет достигнута, а добавление объекта - это просто удобная вещь (как для получателя , так и для отправителя, который позже может быстро найти это письмо снова) - поэтому пользователи более вероятно, ударит отправить без ввода объекта после тела, чем наоборот.

Помещение поля «to» под телом сообщения с другой стороны звучит на самом деле неплохо - в типичной букве один записывает адрес на конверте после , написав само письмо, а также предотвращает доступ неполного сообщения к предполагаемому получателю. Единственное преимущество, которое я вижу в обычной реализации, - это требование убедиться, что на самом деле знает адрес получателя, поскольку, если самый простой способ получить его - позвонить им, можно отбросить почту и напрямую обсудить вопрос вокально ...

ответил Tobias Kienzler 24 Mayam13 2013, 11:20:32
9

Я хотел бы подойти к этому вопросу с другой точки зрения, чем другие ответы.

Что в заказе

Основной вопрос заключается в вопросе философии и методологии упорядочения полей форм.

С одной стороны, можно было бы заказать их в том порядке, в котором автор должен был их написать. Это совершенно разумная ментальная модель того, как может быть изложена форма. Вы могли бы назвать это ориентированным на автора макетом или, возможно, упорядочением потока сознания.

Однако культурная реальность заключается в том, что это не то, как формы выкладываются в Интернете или в автономном режиме, и это на самом деле совершенно не связано ни с каким форматом файла или протоколом передачи, который был опубликован.

  

В начале была бюрократия,
  И Бумага была с бюрократией,
  И Бумага была бюрократией.

В какой-то момент кто-то должен был решить, какой порядок выкладывать поля формы, и в игру вступают два общих порядка сортировки (исходя из моего прежнего опыта работы в качестве профессионального принтера - я потратил много и много часов на копирование, модификацию и разработку форм ):

Сортировка по величине важности и сортировке по порядку обработки

Если вам нужно больше примеров, чем вы можете, посетите IRS Forms and Publications

В каждом случае стандартный порядок формы выглядит следующим образом:

  1. Неявный, для кого эта форма. В государственных учреждениях это опускается как очевидное, так как формы IRS предназначены для IRS, юридические документы для судов и т. Д.
  2. Что это касается - номер формы, название и т. д.
  3. Расскажите нам, что нам нужно знать - ваша информация, жалобы, «тело сообщения» и т. д. здесь.
  4. Подпишите здесь - или «скажите нам, кто вы снова - на этот раз, с чувством!»

В целом цель формы заключается в наложении порядка на набор данных, включая категоризацию, стандартизацию, полноту и т. д. Это, как правило, для всех, как письмо, которое обеспечивает недостаточную информацию или занимает больше времени для обработки, замедляет время отклика и делает больше работы для всех участников.

Автор-Centricity

С появлением компьютера стало возможным представить формы способами, которые не зависели от того, как форма должна была использоваться после ее заполнения. Это изобретение в основном применяется к полям автозаполнения и скрытой формы (например, вам не нужно заполнять «из» вашего почтового клиента, даже если протоколы электронной почты требуют этой информации).

Однако упорядочение полей в значительной степени не изменилось по сравнению с печатной формой. Общий вопрос здесь: «Почему это по-другому?» Здесь нужно нарушать ожидания пользователей, и это нужно делать только тогда, когда есть ясная, популярная и убедительная причина для этого.

В заголовке или нет

Понятие «субъект» и «название» - это очень специфические культурные конструкции; на самом деле, в некоторых культурах и контекстах названия были полностью опущены, например, в работах Джал-ад-Д «« Мухаммад RÅ «mÄ « Коулман Баркс (популярный переводчик) обычно добавляет названия к определенным стихам, но отмечает, что названия полностью принадлежат ему. В Персии 13-го века поэты считали достаточное для себя стихотворение в контексте тома /книги /рукописи, и, ссылаясь на конкретное стихотворение, первые несколько слов или строк часто использовались в качестве метки.

Однако в современной западной культуре эта практика неслыханна - название письменной работы имеет особое значение и считается особо важным. Важность названия или предмета - до сих пор расширяет, что теперь регулярная письменная корреспонденция большего веса, чем «мгновенное сообщение», обновление социального статуса или твит, имеет собственный титул. Черт, вы вряд ли сможете сделать это через 10 страниц книги, не имея не только новой главы, но сама глава часто имеет заголовок, подзаголовок и дюжину подзаголовков между главами.

Кто пришел первым: субъект или тело

В письменных работах, будь то быстрое письмо или рукопись левиафана, связь между телом послания, предметом, с которым он имеет дело, и идеальным названием или кратким резюме, не является ни универсальной, ни однонаправленной.

Эта реальность вызвала создание концепции «рабочего названия». И на первом месте часто меняются люди, настроение и тема. Возможно, вы знаете, что хотите пожелать кому-то счастливого дня рождения, и поэтому вопрос о письме довольно очевиден и является первым, что написано; то же самое можно было бы сказать о объявлении собрания, выпуске отчета о доходах и т. д.

Иногда, однако, каждый знает, что нужно что-то сказать, прежде чем кто-то узнает, что нужно сказать или даже кто это скажет. Таким образом, не должно быть строго соблюдаемого порядка, чтобы форма была заполнена, поскольку это простое отражение реальности того, как людииспользуйте электронную почту.

В других формах также можно ожидать, что кто-то может пройти и заполнить определенную информацию, а затем вернуться и заполнить другие поля, когда будет найдена другая информация. Опять же, это хорошо, хотя переупорядочить форму, основанную на предполагаемой доступности данных, будет в лучшем случае обременительным и запутанным.

Что нужно сделать дизайнеру хорошего пользовательского стиля?

Если каждый заполняет форму в другом, непредсказуемом порядке, в каком порядке должны размещаться поля? Ну, в почтовых программах, как в цифровых формах, старая стандартная система заказов используется для соответствия ожиданиям существующих пользователей. Чтобы обеспечить наилучший пользовательский интерфейс, не следует пытаться принудительно выполнять определенные заказы, например, создавая многоэтапный мастер, который настаивает на том, что это To, Subject и Message являются дискретными транзакциями, которые не должны заполняться в каком-либо другом порядке.

Другой вопрос: каков недостаток в случае OP, предпочитающий сначала заполнить тело и полностью пропустить предмет? Ну, добавьте дополнительную кнопку (Tab) или щелкните мышью. Если нет глупого использования валидации формы, которая угасает, если кто-то сначала не вводит предмет, тогда не должно быть никаких проблем - одна форма, чтобы разочаровать их всех. О да, давайте не забывать, что люди действительно ненавидят формы; они просто делают. Таким образом, с распространенными формами редко бывает более быстро раздражать людей, чем перемещать вещи, чтобы заставить их больше думать о рутинной задаче, которую они бы вообще избегали.

Что касается необходимости прокрутки назад или вниз, чтобы отредактировать /добавить тему, многие (большинство?) почтовых клиентов переместились в систему, где To, CC, BCC и Subject все прикреплены к верхней части документа, пока у самого тела есть своя полоса прокрутки - поэтому добавление /удаление /редактирование получателей и темы не более чем на один клик. Зачем? Потому что, эй, иногда ты не знаешь, о чем говоришь, пока ты не закончишь, или ты понимаешь, что лучше всего, чтобы ваш босс просто разорвал.

(Ссылка на персидскую духовную поэзию 13-го века относительно почтовых клиентов? Да, я пошел туда. Это как раз то, как я ролю.)

ответил BrianH 24 Mayam13 2013, 00:52:59
6

Как читатель, я хочу знать: «Почему вы отправляете мне это письмо?» поэтому я знаю, стоит ли мне читать его сейчас, а не делать все эти важные вещи в моем списке дел.

Как читатель, я ожидаю, что писатель узнает, почему они отправляют мне электронное письмо, и, более того, я надеюсь, что они узнают, почему они отправляют мне электронное письмо, прежде чем они начнут сбрасывать поток информации о сознании в большое белое пространство.

Если они хотят, чтобы я инвестировал свое время на чтение, я надеюсь, что они сделают мне любезность, прежде всего, чтобы рассмотреть вопрос о том, что все, что они собираются написать, будет иметь для меня какое-либо значение - или я буду тратить впустую мое время, прочитав его.

Итак, как автор, подумайте о том, «что заставило меня нажать кнопку« написать сообщение »». Я бы подумал, что «Мысли после нашего телефонного чата» будут достаточными в качестве темы, если это то, что будет представлять собой контент, например. Если вы не знаете, почему вы отправляете мне сообщение, я не знаю, почему я должен его прочитать!

Итак, как разработчик, я бы хотел, чтобы force поощрял всех, кто мог подумать о том, чтобы отправить мне письмо, чтобы подумать о why , они предпочитают это делать, до они фактически начинают избивать клавиши на клавиатуре.

ответил Bill Michell 23 Maypm13 2013, 15:24:05
2

Это простая иерархия информации. Так же, как бумага имеет автора и название вверху, так же как и электронная почта.

Теперь можно утверждать, что это важно только для читателя, а не для автора. И я думаю, что это правильный аргумент. Тем не менее, когда мы читаем электронные письма, у них есть определенная иерархия, и одинаково допустимый аргумент заключается в том, что шаблон, используемый для создания электронного письма, должен соответствовать тому, как мы его читаем.

В конце концов, наличие темы над телом не заставляет пользователя сначала заполнять его. Поэтому, скорее всего, это не главное соображение удобства использования. Это также небольшая линейка информации, которая настолько легко вписывается в видимую область (тогда как ее размещение под телом может скрыть ее, что приводит к путанице).

ответил DA01 23 Maypm13 2013, 21:24:00
1

Я могу только подумать о двух конкретных оправданиях для этого:

  1. Назад, когда это не стандартное соглашение, вероятно, не было большой разницы между длиной строки темы и текстом тела (вспомните о начале текстовых сообщений и даже twitter ). Учитывая способность и удобство добавления большого количества вещей в электронные письма сейчас, один естественный ход событий - это люди, которые могут добавить столько, сколько они могут. К сожалению, это означает, что люди теперь злоупотребляют использованием сюжетных линий (например, продавцы и маркетинг), а также основной текст (например, типичная почтовая сеть).

  2. Полезно структурировать вход для автора таким же образом, что читатель может посмотреть на информацию, а принцип постепенного раскрытия информации для людей, которые хотят узнать больше, работает лучше, если резюме (т.е. строка темы) помещается перед текстом тела. Конечно, это не оправдывает того, является ли оно более удобным для пользователя, но, учитывая, что никто не предоставил другой способ ввода информации, ничего не было сделано об этом.

Как и во всех вопросах удобства использования, лучший способ - попробовать и посмотреть, что произойдет. Если вы размещаете веб-страницу, которая принимает вход по-другому, укажите ссылку!

ответил Michael Lai 23 Mayam13 2013, 10:43:50
1

Я подозреваю, что люди пишут приложения электронной почты таким образом, потому что другие люди так писали приложения электронной почты, и все привыкли к этому. Пользователи ожидают, что, когда они столкнутся с совершенно незнакомым приложением электронной почты, он предложит им тему в верхней части формы заявки и тело ниже. Пользователи получают то, что они ожидают, и не думают о параллельном мире, в котором он отличается. Пользователи будут даже раздражаться, если программное обеспечение не соответствует их ожиданиям. («Sheesh, где я помещаю свою тему в эту чертову вещь?»). Поэтому изменения в пользовательском интерфейсе для составления электронной почты должны быть очень тщательно разработаны для «обратной совместимости» с ожиданиями пользователей.

Хорошая идея, если она выполнена хорошо, может быть флажком, чтобы субъект автоматически генерировался из блеска тела сообщения, при условии окончательного утверждения пользователя. Или, может быть, три варианта выбора сюжетной линии. Это может даже предложить улучшение для пользователя, если пользователь ввел его:

  

Для этого сообщения "me" может быть более наглядным темой, чем "you". [Accept] [Reject]. "

:)

ответил Kaz 23 Maypm13 2013, 20:37:33
0

Здесь есть две перспективы. Вы говорите о своей (писательской) перспективе, и кажется, что размышление о соответствующем названии требует немного внимания, но когда вы смотрите на точку зрения читателя, у него есть смысл прочитать заголовок (название письма) перед Континентом.

В вашем контексте вы, похоже, используете EMAIL AS A MESSAGE, и здесь идея использования заголовка кажется менее понятной, но все же наличие темы в «сообщении электронной почты» не является неудобным.

Что касается удобства использования, я вижу, что это нормально, но это может быть не в соответствии с вашими личными предпочтениями. Персонализация интерфейса - еще один слой поверх удобства использования.

ответил Salman Ehsan 23 Mayam13 2013, 10:48:34
0

Всякий раз, когда вы общаетесь через печатные носители, это неписаная норма, которая включает заголовок /заголовок. Функция заголовка состоит в том, чтобы суммировать следующий контент (в одной строке). Вы видите это в газетах, журналах, плакатах, презентациях и т. Д.

Представьте себе журналы и новостные статьи без заголовков. Как вы даже решаете, что хотите читать? Лицо, получающее 100-е адреса электронной почты, должно каким-то образом фильтровать электронные письма, не читая их. Титулы обеспечивают хороший механизм для этого. Сначала выберите суть сообщения, а затем расскажите о деталях.

Включение пункта заголовка в букву; да, вы делаете это, особенно, на официальных письмах, таких как приложения для работы и прочее.

Относительно размещения поля ввода заголовка в сообщении электронной почты. Я на самом деле думаю, что неплохо было бы задуматься о перемещении заголовка под телом. НО, для получателя, заголовок должен быть наверху из-за вышеупомянутых причин.

ответил rk. 24 Mayam13 2013, 01:31:21
0

У меня была другая мысль, и это связано с тем, как вы используете клавиатуру.

Я обычно закладываю между полями в форме. Однако, когда-то в теле, клавиша Tab должна быть захвачена, поэтому вы можете ввести символ табуляции в качестве отступа.

Если объект появляется после Тела в порядке табуляции, я не могу на него добраться, не переключаясь на мышь или используя какой-либо ключ-модификатор.

В нормальном потоке вещей это было бы довольно разрушительно.

ответил Bill Michell 24 Maypm13 2013, 21:44:40
0

Это вопрос производительности задачи. Как люди пишут письма? Интерфейс должен поддерживать производительность задачи.

Сверху вниз: субъект сначала влияет на тело

Снизу вверх: тело сначала влияет на субъекта

Оба процесса работают, а когда использовать какой подход управляется контекстом. Поэтому поддерживайте оба подхода, не нарушая при этом потока, либо предоставляя без усилий возможности либо ничего не делать, либо вводить /редактировать тему (и другие поля) во всех точках задачи.

ответил uxzapper 26 Mayam13 2013, 05:26:32
0

Это не имеет значения.

См. раздел «Почта Google».

Снимок экрана из Google Mail composer

Легко вернуться в поле Subject. Просто нажмите внутри поля или нажмите Shift-Tab.

И почему Google Mail поставила поле Subject над телом? Потому что все это делают. Другие объяснили уже почему. Предметом является заголовок, предшествующий тексту тела (см. RFC822 ). Или эта последовательность заставляет пользователя думать о том, что он хочет передать. И так далее. И это правда, что порядок шагов изменяет способ выполнения пользователями задачи.

Но это не имеет большого значения.

Так как легко вернуться назад, я часто пропускаю поле Subject и начинаю с тела.

ответил nalply 12 Mayam14 2014, 11:45:12

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132