Здравствуйте,

Имеется задача: Показать диалоговое окно подтверждения с кнопками OK и KO для подтверждения отмены Обращения (Case), если пользователь нажал на статус Cancel в DCM.
Если была нажата кнопка OK, то Case отменяется.
Если была нажата кнопка KO, то Case вернется к предыдущему статусу.

Я попытался отобразить диалоговое окно по событию OnSaving объекта Case.
Вот моя функция:

public override void OnSaving(object sender, EntityBeforeEventArgs e) {  
string status = UpdateData(sender);
if(status!="Canceled") {
base.OnSaving(sender, e);
  	} else {
    		//Todo: Show dialog with question
  		//Todo: Get response OK or KO
                /*if(response ="OK"){
                        base.OnSaving(sender, e);
                 }else{
                        e.IsCanceled = true;
        }*/
}
}

К сожалению, я не нашла никакой информации о том, как отобразить диалоговое окно на стороне сервера.
Я знаю способ отправки сообщений с клиентской стороны (this.showConfirmationDialog(message, function(returnCode)), но не знаю, как вернуть результат нажатия кнопки на сервер для завершения метода OnSaving.

private void SendMessage(object sender) {
       var entity = (Entity)sender; 
       var userConnection = entity.UserConnection;
      string senderName = "MySenderNameCase";  
      string message = JsonConvert.SerializeObject(new {test = "status"});
      MsgChannelUtilities.PostMessage(userConnection, senderName, message);
  }             

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

Нравится

2 комментария
Лучший ответ

Мы делали подтверждение перехода Case на финальный статус на странице, выдавая showConfirmationDialog в функции Save.

 

this.showConfirmationDialog(confirmationMessage.message, function(result) {
    if (result === Terrasoft.MessageBoxButtons.YES.returnCode) {
        this.save(scopeArguments);
     } else {
        this.onDiscardChangesClick();
    }
}, ["Yes", "No"]);

 

Мы делали подтверждение перехода Case на финальный статус на странице, выдавая showConfirmationDialog в функции Save.

 

this.showConfirmationDialog(confirmationMessage.message, function(result) {
    if (result === Terrasoft.MessageBoxButtons.YES.returnCode) {
        this.save(scopeArguments);
     } else {
        this.onDiscardChangesClick();
    }
}, ["Yes", "No"]);

 

Здравствуйте, Владимир.

Спасибо за ваш ответ.

 

Это помогло решить задачу!

 

Показать все комментарии
Добрый день!Предлагаю подумать в возвращении кнопок "Да" и "Нет" в диалоге подтверждения на свои места. Интуитивно кнопка "Да" ищется всегда слева. Если это сделано для того, чтобы пользователь сознательно удалял запись, то, на мой взгляд, это не лучшее решение. Пользователь рано или поздно привыкнет к порядку кнопок в BPM и будет очень обидно, когда, например. в MS Word пользователь не сохранит свой документ, т.к. там кнопки расположены в привычном для всех порядке.
15 комментариев

Добрый день Александр!!!

я считаю, что предложенный вариант компанией Террасофт правильный, так как пользователь как раз интуитивно всегда нажимает на Левую первую кнопку и даже не задумывается, а требуется ему выполнить данное действие или нет. По вопросу сохранения документа Word и всех документов MSOffice то здесь существует автосохранение и в темповой директории всегда можно найти автосохраненную версию документа.

Сохранение присутствует не только в MS Office. Word были приведен как пример, который будет всем понятен. Обычный пользователь не будет искать свой документ в темповых файлах.
Для того и создал тему в идеях, чтобы узнать мнение общественности.

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

Коллеги, у нас UX тесты тоже показали спорные результаты. Пожалуйста, дайте больше фидбека. Если поддерживаете - голосуйте за идею. Если против - комментируйте. Изменение точечное, сможем внести даже в последние дни перед следующим релизом. Важно понимать, как будет удобно.

Я повторюсь еще раз, что я против данной идеи. Лучше чтобы осталось "Нет" - слева, "Да" - справо. Еще раз повторюсь так пользователь будет более сосредоточенно и осознанно подходить к любому всплывающему информационному сообщению и предупреждению, а не просто игнорировать. Плюс у нас так мозг устроен, что читаем мы текст с Лева на Право. И восприятие информации в наш мозг именно так и поступает. Вот мое мнение.

Я считаю, что за многие годы у людей уже выработалась очень сильная привычка в том, что если кнопок 2, то да слева,если 3 (да, нет, отмена) - то нет посредине. Я лично зашел первый раз в 7.8, точно хотел удалить запись, но с первых двух попыток запись осталась на своем месте(сила привычки), что вызвало некоторое недоумение.
Я не уверен, что не будет обратных ситуаций, в которых пользователь передумав нажмет в "Да", учитывая, что кнопка находится справа. Такого подвоха я просто не ожидал.
Соглашусь с Александром, что подсветки и выбора по-умолчанию более чем достаточно.
У пользователя есть время подумать, пока он ведет мышку к кнопкам.

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

Поддерживаю. Но считаю, что мнения разработчиков в этом вопросе не стоит ставить в приоритет. Ибо зачастую мышление в использовании продукта сильно разнится с мышлением пользователя.
Считаю, что правильнее было-бы доверять тестам. Возможно следует провести дополнительные тесты.

"Ляутин Вячеслав Андреевич" написал:Поддерживаю. Но считаю, что мнения разработчиков в этом вопросе не стоит ставить в приоритет. Ибо зачастую мышление в использовании продукта сильно разнится с мышлением пользователя.

Не соглашусь с вами Вячеслав. Так как правильный и хороший разработчик в первую Очередь перед разработкой и при разработки программного обеспечения, всегда должен ставить себя на место пользователя. И предугадывать все шаги пользователя еще как минимум на 100-200 шагов вперед. Меня мой преподаватель по программированию именно этому и учил. А я в программирование с 6 класса школы. Застали эволюцию разных программных систем, домашних и персональных компьютеров. Если бы к примеру мой кумир Стив Джобс не ставил бы себя на место пользователя, он бы не придумал такой гениальный продукт как Айфон, Айпад и так далее.

"Пащенко Александр Сергеевич" написал:Я считаю, что за многие годы у людей уже выработалась очень сильная привычка в том, что если кнопок 2, то да слева,если 3 (да, нет, отмена) - то нет посредине. Я лично зашел первый раз в 7.8, точно хотел удалить запись, но с первых двух попыток запись осталась на своем месте(сила привычки), что вызвало некоторое недоумение.

В жизни как и в программе не может быть "Да", "Нет", "Отмена". На любой вопрос поставленный пользователю или человеку, мы должны отвечать всегда утвердительно или "Да", или "Нет". В жизни не бывает 3-его выхода. У тех людей у которых появляется 3 выход, никогда не бывает четкого и поставленного мнения. Данный тип людей всегда сомневается.

Есть еще одно предложение особенно касаемо Удаления записей. Если есть мнение и тесты к примеру показывают, что люди больше нажимают "Да" - слева, "Нет" - справа. То именно для удаления поступить следующим образом. Первый вопрос об удаление задавать где "Да" - слева, "Нет" - справа. А вот уточняющий вопрос сделать так, что "Нет" - слева, "Да" - справа. И вот тогда я думаю мы будем точно уверенны, что пользователь уже подумав выполнит удаление записи.

где то даже данный подход я видел в жизни.

Начнем с того, что данное диалоговое окно пользователь увидит, если произведет определенную последовательность действий. Т.е. ему для начала необходимо выбрать запись (или несколько записей), нажать на кнопку "Действия", выбрать пункт "Удалить" и только потом он увидит данное диалоговое окно. А теперь вопрос: "Осознает ли пользователь, что он желает УДАЛИТЬ запись?".
Лично мне кажется, что да - осознает, поэтому замечание о том, что:

"Власов Михаил Викторович" написал:

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

не уместно.

Что касается сомой идеи изменения расположения кнопок, то лично я подобного ни в одном популярном ПО не видел.

"Коваленко Владимир Юрьевич" написал:Начнем с того, что данное диалоговое окно пользователь увидит, если произведет определенную последовательность действий. Т.е. ему для начала необходимо выбрать запись (или несколько записей), нажать на кнопку "Действия", выбрать пункт "Удалить" и только потом он увидит данное диалоговое окно. А теперь вопрос: "Осознает ли пользователь, что он желает УДАЛИТЬ запись?".
Лично мне кажется, что да - осознает

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

Поэтому я продолжаю защищать предложенное командой Террасофт "Нет" - слева, "Да" - справа.

"Власов Михаил Викторович" написал:всегда должен ставить себя на место пользователя.

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

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

Конечно понять на сколько реже люди будут допускать ошибки при переносе кнопке довольно сложно, но я думаю что дискуссией в этом топике мы точно не решим этот вопрос :smile:

"Ляутин Вячеслав Андреевич" написал:Конечно понять на сколько реже люди будут допускать ошибки при переносе кнопке довольно сложно, но я думаю что дискуссией в этом топике мы точно не решим этот вопрос

Вопрос сейчас стоит не только о том сколько раз пользователь допустит ошибки но и о Юзабилити. Очень еще интересный пример Возьмем "Окно Microsoft" и "Окно Apple". Как у данных окон располагаются кнопки? у PC - "Свернуть окно", "Расширить окно", "Закрыть окно". у Mac-a "Закрыть окно", "Свернуль окно", "Расширить окно". Плюс у мака они еще и цветами разными выделены. И мне к примеру как пользователю удобно и 1 и во 2 случае работать с окнами. Но как критик предпочтение отдаю Юзабилити Макинтоша. Так же и здесь как бы мы сейчас не разместили клавиши слева на право или справо на лево, всегда рассудит данную ситуацию жизнь и конечный потребитель.

Но для универсальности я бы тогда ввел бы системную настройку Где "true" - означало бы расположение Слева на Право ("Да", "Нет"), и где "false" - расположение Справа на Лево ("Нет", "Да") и как уже пользователю удобно так он и настраивает под себя интерфейс. Вот еще одно из предложений.

Показать все комментарии

В карточке редактирования wnd_...Edit предлагается выделять Caption визуальных контролов для полей Dataset-а с признаком "Только для чтения" цветом, отличающимся от цвета остальных полей, например, зеленым, или выставлять IsEnabled = false.

Нравится

2 комментария

Если заголовки (Caption) визуальных контролов для полей с признаком "Только для чтения" и для других полей имеют один и тот же цвет, то пользователь постоянно путается при вводе данных.
Вот пример решения:

//Модуль scr_BaseDBEditUtils
 
function ProcessBaseDBEditOnPrepare(Window, BaseDBEdit) {
...
    /* Добавляем строчку в функцию... */
    SetCaptionColorForIsReadOnlyFields(Window); //Устанавливает цвет для полей с признаком "Только чтение"
}
 
//Устанавливает цвет для полей с признаком "Только чтение"
function SetCaptionColorForIsReadOnlyFields(Window) {
	for (var i = 0; i < Window.ComponentCount; i++) {
		if (!IsUndefined(Window.Components(i).DataField)) {
			if (Window.Components(i).DataField.IsReadOnly) {
				//Можно включить выделение цветом --> Window.Components(i).CaptionColor = clReadOnlyCaptionColor;
				Window.Components(i).IsEnabled = false;
			}
		}
	}
}

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

Показать все комментарии