Графический интерфейс пользователя

Question

Каков наилучший (ые) способ (ы), чтобы пользователь не запутался в этом "Условии гонки"?

Это может быть очень глупый вопрос.

Один графический интерфейс с окном, поддерживающим операции мыши с объектами в этом окне. Например, пользователь может перемещать, толкать и т. Д. Объект из A -> B. (Это повлияет на пару серверов, поэтому это простая операция с большой мощностью) Если другой пользователь уже что-то сделал с этим объектом, сервер (ы) позаботится о конфликтах, слияниях и т. Д. Но наш оригинальный пользователь должен получить какую-то обратную связь, потому что это может произойти в одно и то же время. (То есть пользователь перемещает объект в одном потоке, а приложение получает уведомления в другом потоке)

Это не имеет никакого отношения к коду, даже если можно утверждать, что поток recv похож на внутреннее хранилище, а графический интерфейс может быть «блокировкой» при нажатии / перетаскивании мыши.

Вы думаете, что уронили Объект на B, но на самом деле он появляется в B ', B' ', C, D (или исчез).

Мне вообще не нравятся MessageBoxes, и даже невозможно всплыть для каждой мелочи. И нет, вы не можете заблокировать объект для пользователя, когда пользователь начинает перетаскивать его (вместо этого подумайте о передаче сообщения)

Возможно, можно использовать анимацию, которая позволит Пользователю увидеть приземление Объекта на B, а затем переместить, анимировать, на B ', B' ', C или D (или испариться).

Answer 1

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

edit: Я должен добавить, что мне нравится идея анимирования, я больше не думаю, что этого достаточно.

Answer 2

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

Я думаю, что поддерживая отзывчивость GUI (как если бы не было параллелизма), а затем, когда обнаружен конфликт, когда вы получаете ответ от другого потока, вы исправляете интерфейс. Мне нравится эффект анимации / испарения, чтобы пользователь знал, что его операция была перезаписана, возможно, с помощью строки состояния (или аналогичного ненавязчивого уведомления) для объяснения измененного графического интерфейса.

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

Answer 3

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

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