Альтернативный способ уведомить пользователя об ошибке

Question

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

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

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

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

Я открыт и для других творческих идей.

Answer 1

Существует несколько альтернатив, которые могут использоваться при возникновении ошибки, каждая из которых имеет свои преимущества и недостатки:

1. Всплывающие окна MessageBox
   Отобразить всплывающее окно сообщения для пользователя.
   Преимущество: , поскольку он является модальным, пользователь должен подтвердить ошибку, чтобы продолжить.
   Недостаток: , поскольку он модальный, он прерывает пользователя от того, что он делал. Многочисленные ошибки также неудобны и требуют многократных подтверждений.

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

3. Сообщения в строке состояния
   Показывать сообщения в строке состояния приложения.
   Преимущество: всегда будет видно на экране, но находится "вне пути" главного окна.
   Недостаток: трудно отображать несколько сообщений и может быть пропущен пользователем.

4. Воздушные шары
   Отображение уведомлений в стиле Outlook / MSN Messenger рядом со значками уведомлений.
   Преимущество: достаточно очевидно для того, чтобы пользователь мог это заметить, но не обязательно требует значок уведомления. Может также объединять несколько сообщений в одно всплывающее окно.
   Недостаток: может раздражать пользователя.

5. Значки уведомлений Показать значок уведомления (возможно, с уведомлением о появлении всплывающей подсказки).
   Преимущество: очевидно для пользователя, но все же ненавязчиво.
   Недостаток: - еще один значок уведомления, чтобы загромождать рабочий стол пользователя.

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

Примеры всплывающих уведомлений, для которых не требуется значок уведомления, см. this для Windows Forms и this для WPF.

Answer 2

Если ваше окно MDI открыто / видно, то на нем может быть значок состояния связи - он будет зеленым, когда все в порядке, оранжевым для предупреждений (например, обнаружены поврежденные пакеты, но связь все еще работает, и система восстановлена), и красный для ошибок (как никакие декодируемые сообщения, полученные в течение 5 секунд). Это позволяет ему быть довольно тонким, когда что-то происходит, но весьма заметно «другое» - проблема возникает.

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

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

Альтернативой визуальным индикаторам является использование звуковых сигналов.

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

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

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

Answer 3

Одна (относительно) распространенная парадигма - поместить сообщение в строку состояния («[x] Новые сообщения») и сделать появление окна сообщения действием пользователя.

Answer 4

это поместило маленький красный кружок справа от контроля. своего рода ячейка данных в стиле erroText

var errorProvider1 == new ErrorProvider();

protected void textBox1_Validating (object sender,  System.ComponentModel.CancelEventArgs e)  
{  
   try  
   {  
      int x = Int32.Parse(textBox1.Text);
      // Clear the error.  
      errorProvider1.SetError(textBox1, "");  
   }  
   catch (Exception ex)  
   {  
      errorProvider1.SetError(textBox1, "Not an integer value."); 
      // additionally, if you wantto prevent user leaving textbox 
      // until he satisfies condition. uncomment below.
      // e.handled = true; 
   }  
}  

От: Microsoft

Answer 5

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

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

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