AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Функционал
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 12.01.2012, 14:14   #1  
ta_and is offline
ta_and
Участник
 
226 / 122 (5) +++++
Регистрация: 26.02.2002
Адрес: СПб
Серые кнопки. Изначально неверное решение.
Предыстория:
В стандартной функциональности Ахарты повсеместно используются "серые" кнопки.
То есть в какой-то момент времени кнопка доступна, а в какой-то момент времени она становится недоступной и пользователь не может на нее нажать.
Казалось бы - о! Как здорово! Пользователю не даем делать то, что ему нельзя!
На самом деле - все совсем не так.
Мне кажется - это абсолютно НЕВЕРНОЕ решение.
Серые кнопки в многопользовательской среде - это полный абсурд!
А теперь обосную свою точку зрения.

Доводы
Почему НЕЛЬЗЯ делать кнопки недоступными


1. Ахарта - многопользовательска среда.
И если эта конкретная кнопка в данный момент на данной форме недоступна, то это НЕ ОЗНАЧАЕТ, что это действие в данный момент времени на данной форме совершить нельзя. Это означает, что в момент, когда открывались текущие данные это действие делать было нельзя. Но через буквально полсекунды после того, как эта кнопка отобразилась недоступной, какой-то другой пользователь сделал действие, которое РАЗРЕШАЕТ действие по данной кнопке. Но текущая форма (а следовательно и пользователь) об этом еще НЕ ЗНАЮТ. В итоге - только после обновления данных становится возможным сделать уже давно доступную операцию.

Еще хуже, если кнопка в момент отображения данных доступна.
На самом деле - какой-то другой пользователь уже мог сделать другую или эту же операцию со своего рабочего места! Но текущая форма (а следовательно и пользователь) об этом еще НЕ ЗНАЮТ. Пользователь радостно жмет на доступную кнопку.... И тут масса вариантов. От корректного отображения ошибки (если программист был хороший) до полного бреда в данных и краха базы.

2. Информативность.
Основное объяснение почему надо сделать недоступную кнопку от постановщиков задачи и конечных пользователей:
"Вот кнопка серая и пользователь сразу видит, что данную операцию делать нельзя."
Даже если не принимать в расчет довод №1 о многопользовательской среде, все равно данное объяснение не выдерживает никакой критики по одной простой причине.

"ПОЧЕМУ нельзя?!"

А ведь данный вопрос постоянно возникает перед пользователем, когда он видит серую кнопку.
Хорошо, если пользователь опытный. Он знает, что разнесенный заказ уже нельзя больше разнести. Тут и тупой сообразит. А что делать, если недоступна кнопка например изменения настроек? Вот она была доступной, и вдруг стала недоступной.
Почему?! И побежал бедный неопытный пользователь к более опытному товарищу.
Более опытный товарищ посмотрел на эту серую кнопку, почесал репу, и сказал "Не знаю". И побежали они оба к консультанту. Консультант посмотрел на эту серую кнопку, почесал репу, и сказал "Не знаю". И побежали они втроем к программисту. Программист поставил точку останова на форме и посмотрел в коде отчего же эта кнопка все таки серая... Ага. Вот почему!!! Все стало ясно и понятно. Все правильно. Она должна быть серой. Все довольны, все смеются.

Всего этого можно было бы легко избежать, если бы кнопка оставалась доступной, но перед началом операции была сделана обязательная проверка на допустимость совершаемых действий. И если вдруг данное действие в данный момент времени запрещено, то пользователю было бы выдано ясное и понятное сообщение ПОЧЕМУ этого делать нельзя. Сразу снимается куча вопросов.

3. Информативность. Пункт два.
Возражение от постановщиков задачи и конечных пользователей:
"Но ведь пользователь сразу хочет видеть что данное действие недопустимо, не нажимая на кнопку!"
Даже если не принимать в расчет довод №1 о многопользовательской среде, все равно, данное требование не удовлетворяется Недоступностью кнопки.
Потому что для того, чтобы увидеть, что данное действие недоступно нужно обязательно сделать текущими просматриваемые данные. Например в гриде выбрать определенную запись. И если нужно просмотреть допустимость действия по ста записям, нужно встать на каждую!! из этих ста записей. Поэтому "сразу" это не аргумент.
Сразу - это выведенная иконка для каждой записи в гриде или информативное дисплейное поле.
Например, если по какой-то записи нужно отображать - есть дочерние документы или их нет, то делать кнопку открытия дочерних документов недоступной - не информативно.
Намного лучше - вывести дисплейную иконку для каждой строки грида, отображающую что документы есть. И можно даже этой иконкой отобразить в каком статусе эти документы.
Подобное, более оптимальное и информативное решение, альтернативное "серой кнопке", можно найти в каждом конкретном случае.

4. Производительность.
Играться с доступностью кнопки – ресурсоемкое занятие.
При каждом действии пользователя, форма должна отслеживать какие данные изменились и делать запрос к базе данных для того, чтобы определить какие кнопки делать недоступными, а какие нет.
Таких запросов может быть очень много (если много кнопок на форме) и эти запросы будут валиться к базе данных ПОСТОЯННО. При каждой смене строки.
Если же продумать более верное решение - например дисплейное поле, то запрос к базе данных будет сделан только для отображаемых в данный момент записей. один раз. может быть несколько запросов, но все равно их будет меньше, чем при постоянной проверки допустимости кнопок.

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



Вывод
Серые кнопки - ЗЛО.
Все должны это понимать.
Даже если все же принимается решение делать конкретную кнопку недоступной при некоторых критериях, мы должны обязательно принимать во внимания изложенные выше соображения.



ПС
Не смог сдержать крик души.
На каждом проекте - одно и то же!
Серые кнопки... серые кнопки... серые кнопки.
И на каждом проекте приходится с ними долго и упорно сражаться и жить....
Я не призываю полностью отказаться от серых кнопок.
Я не призываю переписать уже имеющийся функционал.
Давайте хоть новую функциональность проектировать грамотно?
За это сообщение автора поблагодарили: S.Kuskov (5), Ivanhoe (3), Lucky13 (3), Roman777 (2), rINT (1), pitersky (2), Bega (2), e@gle (3), mazzy (2), Corkscrew (1), Logger (2).
Старый 12.01.2012, 14:56   #2  
_scorp_ is offline
_scorp_
Участник
Аватар для _scorp_
MCBMSS
 
488 / 369 (13) ++++++
Регистрация: 25.07.2007
Адрес: Москва
Я бы не был столь категоричным

Цитата:
Сообщение от ta_and Посмотреть сообщение
1. Ахарта - многопользовательска среда.
Поэтому нужно и программировать с учетом, что среда многопользовательская. Яркий пример форма складского журнала. Обратите внимание на метод formMethodTimeOutRedraw в классе JournalFormTable, который как раз и занимается обновлением текущего курсора через определенные моменты времени.

Цитата:
Сообщение от ta_and Посмотреть сообщение
Информативность.
На это должны быть пользовательские инструкции. Да HelpText для кнопки никто не отменял.

Цитата:
Сообщение от ta_and Посмотреть сообщение
Производительность.
Такие кнопки обычно кидаются в подменю, чтобы не устраивать "светомузыку" на форме. В таком случае не так уж и часто вызываются всякие проверки.

Цитата:
Сообщение от ta_and Посмотреть сообщение
Программируемость.
Для того, чтобы сделать кнопки серыми мы никак не можем обойтись без программного кода на форме.
Используйте классы. Смотрите опять же в сторону JournalFormTable.

Цитата:
Сообщение от ta_and Посмотреть сообщение
К тому же, обычно, код, который делает кнопки недоступными, полностью дублирует (должен дублировать!) код проверки допустимости совершения конкретного действия.
Проверка - есть законченное действие. Нужно выносить её в отдельный метод. Потом вызывайте этот метод сколько душе угодно. Никакого дублирования нет.
За это сообщение автора поблагодарили:  (1), gl00mie (2).
Старый 12.01.2012, 15:12   #3  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Довод "Многопользовательская среда", имхо, натянут.
Довод "Информативность" очень подкупает. Выскажу своё мнение по поводу информативности. "Информативность" полезна при обучении. При активной работе более приоритетными становятся другие требования к интерфейсу. Я бы не смешивал вместе эргономику рабочего интерфейса и контекстной справки.
Цитата:
Сообщение от ta_and Посмотреть сообщение
Подобное, более оптимальное и информативное решение, альтернативное "серой кнопке", можно найти в каждом конкретном случае.
Иногда "серая" кнопка несёт в себе информацию не столько о недоступности выполнения соответствующей операции, сколько о необходимости выполнения соседней. Она направляет действия пользователя в нужное русло. Указывает очерёдность выполения операций.
Т.е. допустим, что для обработки некого документа необходимо провести его через 5 статусов. Для этого делаем 5 кнопок расположенных друг под другом. Пусть специфика процесса такова что некоторые статусы можно перепрыгивать, а некоторые нет. Если кнопки всех статусов будут всегда активны, то как довести до пользователя информация о том какой из статусов может быть пропущен а какой нет?

Также немаловажную роль играет психологический момент. Система, которая "раньше" ограничивает пользователя в неправильных действиях, предвосхищая ошибки, субъективно вызывает больше доверия.
За это сообщение автора поблагодарили: lev (5), egorych (5), _scorp_ (5).
Старый 13.02.2020, 22:35   #4  
ta_and is offline
ta_and
Участник
 
226 / 122 (5) +++++
Регистрация: 26.02.2002
Адрес: СПб
Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
Также немаловажную роль играет психологический момент. Система, которая "раньше" ограничивает пользователя в неправильных действиях, предвосхищая ошибки, субъективно вызывает больше доверия.
Единственный вменяемый аргумент в пользу серых кнопок.
----------------------------
Сегодня опять возникла эта свистопляска с серыми кнопками. : )
Есть кнопка на форме Подтвердить.
Она серится стандартным кодом, который вызывает для этого грамотно написанный стандартный класс статусов для текущей записи. Здорово!
Да вот беда.
Пользователи видят серую кнопку и спрашивают - Почему она серая?!
А серой она может быть по очень многим причинам, начиная со статуса записи заканчивая заполненностью полей.
И вот бедные пользователи спрашивают у консультанта - Что не так?
Хорошо, консультант как раз грамотный. Сразу перечень критериев выдает...
Ну это понятно... : )
Еще раз подчеркиваю это СТАНДАРТ.
Какие есть идеи?
1. Отменить проверку "серости" кнопки, сделать ее всегда доступной БЕЗ гарантии, что при ее нажатии все будет хорошо. Потому что для того, чтобы узнать а что же может быть не хорошо, это нужно прошерстить весь код обработки чтобы точно убедиться, что все критерии доступности кнопки проверяются.
2. Сделать дополнительную кнопку Проверить по которой запускать тот же класс проверки но уже с выводом сообщений. И не факт, что все нужные сообщения будут выведены, потому что класс проверки изначально планировался как вспомогательный и ТИХИЙ. Ну типа нажали Проверить, а сообщений никаких нет. Типа все хорошо. Но кнопка осталась серой. Нужно будет смотреть стандартный класс и выводить нужные сообщения.
-----------------------------------------
А теперь предположим, что в стандарте
1. сделали класс для выполнения функции подтверждения. Возможно, с наследниками для каждого статуса.
2. все проверки сделали внутри этого класса и его наследниках, возможно с использованием дополнительной структуры классов, обслуживающих именно статусы. Все проверки изначально с выводом сообщения об ошибке или недопустимости действия.
3. кнопку Проверить на форме НЕ проверяли и НЕ делали серой.

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

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

----------------------------------------

Уважаемый Link.
Вы сами себе противоречите.
Вы говорите, что полностью со мной не согласны насчет серых кнопок.
А потом жалуетесь на то, что вот серые поля - это да... это беда....
Извините меня, пожалуйста, но это одни и те же доводы.
Серые кнопки = серые поля.
И при грамотном проектировании как раз проверки делаются в методах validate*, на таблице, а не тупым запрещением редактирования на форме или на источнике данных. Конечно, если поле в принципе не может быть изменено, то оно может быть нередактируемым. Но делать недоступными поля, которые можно изменять при каких-то условиях, при каких-то нельзя - это плохое проектирование. Ровно аналогично с серыми кнопками. Как раз если поле запрещено для редактирования на форме программно - это прямой путь к грубым ошибкам в данных. Потому что есть такая возможность вытащить поля из источника данных при настройке форм. и тут... вся такая бизнес-логика построенная на недоступности полей вообще идет далеко и надолго.

Разберу пару Ваших доводов:
Цитата:
Сообщение от Link Посмотреть сообщение
Имхо подход с неактивными кнопками очень удобен, функционален и информативен.
Голословное утверждение, доводы против неактивных кнопок я привел в этой статье.

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

Цитата:
Сообщение от Link Посмотреть сообщение
Пункт с производительностью мне вообще непонятен
Извините за нескромный вопрос.... как Вы думаете работает проверка доступности кнопки и запрет ее доступности?
Я очень грубо опишу Вам этот процесс:
1. После активации записи срабатывает код active на источнике данных.
2. Срабатывает код, который анализирует критерии доступности кнопки. Подчеркиваю, при ЛЮБОМ выборе ЛЮБОЙ записи срабатывает данный код.
2.1. В лучшем случае идет проверка имеющихся полей в источнике данных и принимается решение о доступности кнопки.
2.2. Чуть хуже, но еще ничего так... идет вызов методов класса, которые выполняются на сервере.
2.3. Еще хуже - класс обработчик инициализирован на клиенте и он делает проверки дергая запросы к базе данных.
2.4. Ну и верх совершенства - код расположен прямо на форме (не важно в кнопке, на форме или на источнике данных)
Как Вы думаете, это НЕ влияет на производительность?
Причем, в отличии от дисплейных методов полученные результаты НЕ могут быть закешированы. (Надеюсь, понятие кэширования Вам знакомо)
3. В зависимости от результата проверки устанавливается свойство контрола на форме - доступен-недоступен. При этом ПЕРЕРИСОВЫВАЕТСЯ вся форма или ее часть, в зависимости от того, где это свойство устанавливается и было ли залочено обновление формы до выполнения данной операции. В любом случае, при изменении свойства форма перерисовывается.
Как Вы думаете, это НЕ влияет на производительность работы формы?

Цитата:
Сообщение от Link Посмотреть сообщение
, так как считаю что данный прием используются на гриде, где данные уже прочитаны и нет необходимости обращаться к БД вновь.
Думаю, что запросы к базе данных при проверке доступности делаются в большинстве случаев. Хотя, я статистику не вел. Возможно, тут я ошибаюсь.

Цитата:
Сообщение от Link Посмотреть сообщение
Если такая необходимость есть, то конечно тогда проще сделать проверку по нажатию кнопки - помоем это логично и понятно для любого программиста.
Вы это о чем сейчас? Я говорю о принципах проектирования интерфейса, а вы говорите о конкретной реализации кода? Не передергивайте. И не считайте, пожалуйста, меня иррациональным и не понятливым.

Если вы приведете разумные доводы, я Вас выслушаю.

----------
Рассматривать предположения "Неплохо было бы..." я не буду, так как мы живем в реальной системе и ее свойства достаточно жестко ограничены Microsoft.
Старый 14.02.2020, 12:36   #5  
ta_and is offline
ta_and
Участник
 
226 / 122 (5) +++++
Регистрация: 26.02.2002
Адрес: СПб
Цитата:
Сообщение от ta_and Посмотреть сообщение
3. кнопку Проверить на форме НЕ проверяли и НЕ делали серой.
Читать как
3. кнопку Подтвердить на форме НЕ проверяли и НЕ делали серой. Кнопка просто вызывает класс-обработчик, в котром делаются все проверки и выдаются соответствующие сообщения если обнаружена ошибка или недопустимое действие.
Старый 14.02.2020, 12:37   #6  
ppson is offline
ppson
Участник
Аватар для ppson
Ex AND Project
1C
 
2,102 / 114 (8) +++++
Регистрация: 25.06.2002
Адрес: SPb, Msk
Цитата:
Сообщение от ta_and Посмотреть сообщение
Пользователи видят серую кнопку и спрашивают - Почему она серая?!
А серой она может быть по очень многим причинам, начиная со статуса записи заканчивая заполненностью полей.
И вот бедные пользователи спрашивают у консультанта - Что не так?
Хорошо, консультант как раз грамотный. Сразу перечень критериев выдает...
Ну это понятно... : )
Еще раз подчеркиваю это СТАНДАРТ.
Какие есть идеи?
Есть идея отправить пользователей читать инструкцию по интерфейсу системы.
И пользователи не бедные, а безграмотные и самоуверенные.
__________________
Старый 12.01.2012, 15:39   #7  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
Я не дочитал, но в общем случае, я полностью согласен.
На самом деле, в NAV вроде даже делали прототип, который делал как раз оповещение, если нельзя, с детальной причиной.
Думаю, в АХ это тоже когда-то появится.
За это сообщение автора поблагодарили: Logger (1).
Старый 12.01.2012, 16:18   #8  
Link is offline
Link
Британский учённый
Аватар для Link
Соотечественники
 
568 / 513 (19) +++++++
Регистрация: 25.11.2005
Адрес: UK
Записей в блоге: 9
Я дочитал и полностью не согласен.

Имхо подход с неактивными кнопками очень удобен, функционален и информативен.

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

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

Если продолжать мысль автора, то тоже самое можно сказать про запрет редактирования полей, это ведь нужно настраивать свойства поля, а то и возможно в коде менять свойства в рантайме, обращаться к базе, а это ресурсоемкая задача. Можно ведь разрешить редактировать любое поле, а потом выполнять проверку и выводить оповещение с детальной причиной, если обновить поле нельзя.
__________________
Людям физического труда для восстановления своих сил нужен 7-8 часовой ночной сон. Людям умственного труда нужно спать часов 9-10. Ну а программистов будить нельзя вообще.
Старый 14.01.2012, 11:51   #9  
Pustik is offline
Pustik
Участник
 
807 / 372 (14) ++++++
Регистрация: 04.06.2004
Цитата:
Сообщение от kashperuk Посмотреть сообщение
Я не дочитал, но в общем случае, я полностью согласен.
Так нельзя.Это неуважение к автору.
__________________
-Ты в гномиков веришь?
-Нет.
-А они в тебя верят, смотри, не подведи их.
Старый 12.01.2012, 17:56   #10  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Главное преимущество программного вывода сообщения над статической пусть и контекстной справкой в том, что в рантайм есть возможность определить истинную причину недоступности той или иной операции и включить в текст сообщения конкретные значения обрабатываемых величин. В то время как в справке может находится пусть и полный но общий перечень причин. Пользователь читающий такую справку может лишь догадываться из-за каких именно причин кнопка или текстовое поле заблокированно в данной конкретной ситуации.
Хочется иметь возможность "спросить" у заблокированного контрола причину по которой он заблокирован. Но ради этого делать все контролы доступными - перебор.

P.S.: Если мыслить шире, подобные рассуждения можно применить не только к свойству "доступности" но и ко всем другим. Представьте себе систему, которая могла бы в любой момент объяснить природу происхождения значения той или иной величины в отчёте и на форме на человеческом языке рассказать по каким правилам было рассчитано значение, какие параметры повлияли на расчёт. Не система - мечта . Утопия?
Старый 12.01.2012, 18:26   #11  
Link is offline
Link
Британский учённый
Аватар для Link
Соотечественники
 
568 / 513 (19) +++++++
Регистрация: 25.11.2005
Адрес: UK
Записей в блоге: 9
Вот именно, что утопия. Кнопки это частный случай, я например гораздо чаще сталкиваюсь с необходимостью узнать, почему та или иная галка неактивна или почему система ведет себя именно так, а не как я ожидал. Но почему то обвинили именно кнопки, которые имхо гораздо меньше требуют объяснения при логичной и удачной архитектуре.
__________________
Людям физического труда для восстановления своих сил нужен 7-8 часовой ночной сон. Людям умственного труда нужно спать часов 9-10. Ну а программистов будить нельзя вообще.
Старый 12.01.2012, 22:40   #12  
Кирилл
Гость
 
n/a
Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
Хочется иметь возможность "спросить" у заблокированного контрола причину по которой он заблокирован. Но ради этого делать все контролы доступными - перебор.
Можно просто закрашивать кнопку серым цветом, оставляя доступной для нажатия
С одной стороны получаем некую заботу системы о пользователе, с другой стороны вознаграждаем информативным сообщением об ошибке особо любознательных.

Это конечно извращение, но раз уж пошла такая пьянка ...
Старый 13.01.2012, 08:25   #13  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от Кирилл Посмотреть сообщение
Можно просто закрашивать кнопку серым цветом, оставляя доступной для нажатия
С одной стороны получаем некую заботу системы о пользователе, с другой стороны вознаграждаем информативным сообщением об ошибке особо любознательных.

Это конечно извращение, но раз уж пошла такая пьянка ...
Такие сценарии нужно реализовывать на уровне ядра системы. И чтобы их реализовать нужны принципиальные изменения в объектной моделе контролов. Т.е. например свойство контрола не должно устанавливаться внешним (по отношению к контролу) кодом, а должно вычисляться самим контролом.
Старый 13.01.2012, 09:22   #14  
egorych is offline
egorych
Участник
Самостоятельные клиенты AX
Oracle
 
761 / 154 (7) ++++++
Регистрация: 09.11.2006
Адрес: Краснодарский край
ИМХО поток сознания не до конца формализован, аргументы сильно притянуты за уши!
Согласен с S.Kuskov - проще предупредить неправильные действия юзера, чем разгребать потом что он сделал!
Тем более простым юзерам (кладовщик, например) ну совсем не надо знать почему кнопку нельзя нажать! И сообщения они как правило не читают - "там что-то написано было, но я не прочитал и закрыл"
ИМХО 1 - автор рассуждает как чистый консультант! Поработайте на клиенте с годик хотя-бы и узнаете, что лучше не дать нажать или проверять каждый раз.
ИМХО 2 - "правильный" подход к программированию (все в классы, долой код на форме и т.п.) хорош в теории, в реальной жизни это приводит к DAX2012, где уже нельзя осуществить поиск номенклатуры по наименованию!
__________________
Axapta 3.0 sp - хз какой, kr2
За это сообщение автора поблагодарили: Link (2).
Старый 13.01.2012, 09:49   #15  
pitersky is offline
pitersky
северный Будда
Аватар для pitersky
Ex AND Project
Соотечественники
 
1,486 / 408 (16) +++++++
Регистрация: 26.09.2007
Адрес: Солнечная система
Цитата:
Сообщение от egorych Посмотреть сообщение
проще предупредить неправильные действия юзера, чем разгребать потом что он сделал!
Тем более простым юзерам (кладовщик, например) ну совсем не надо знать почему кнопку нельзя нажать! И сообщения они как правило не читают - "там что-то написано было, но я не прочитал и закрыл"
крайне неубедительные возражения
1) разгребать ничего не надо будет в любом случае. Ни так, ни так никакой обработки данных не будет
2) а вот это совсем неправда. зачем человека держать за дрессированную обезьяну? человек должен понимать смысл того, что он делает и почему он этого сделать не может. хотя бы на самом общем уровне.

в целом я согласен с автором. серые кнопки лучше только в том случае, когда имеются не отменяемые пользователем действия (например, разноска складского журнала - её нельзя отменить, можно только отсторнировать сам журнал). во всех остальных случаях предпочтительнее активная кнопка с проверкой.
__________________
С уважением,
Вячеслав
Старый 13.01.2012, 10:22   #16  
egorych is offline
egorych
Участник
Самостоятельные клиенты AX
Oracle
 
761 / 154 (7) ++++++
Регистрация: 09.11.2006
Адрес: Краснодарский край
Цитата:
Сообщение от pitersky Посмотреть сообщение
крайне неубедительные возражения
1) разгребать ничего не надо будет в любом случае. Ни так, ни так никакой обработки данных не будет
2) а вот это совсем неправда. зачем человека держать за дрессированную обезьяну? человек должен понимать смысл того, что он делает и почему он этого сделать не может. хотя бы на самом общем уровне.
Вы консультант/внедренец?
Понимаете - реалии жизни таковы, что в более-менее большой/средней фирме количество сотрудников, которые могут/а главное ХОТЯТ понимать что они делает достаточно мало. И все они занимают какие-то руководящие должности. А вот люди, которые делают рутинные операции не будут задумываться на д проблемами выскакивающих сообщений! Ну такова жизнь! Может где-то и есть идеальные кладовщики, но их очень мало!
__________________
Axapta 3.0 sp - хз какой, kr2
Старый 13.01.2012, 10:42   #17  
pitersky is offline
pitersky
северный Будда
Аватар для pitersky
Ex AND Project
Соотечественники
 
1,486 / 408 (16) +++++++
Регистрация: 26.09.2007
Адрес: Солнечная система
Цитата:
Сообщение от egorych Посмотреть сообщение
Вы консультант/внедренец?
Понимаете - реалии жизни таковы, что в более-менее большой/средней фирме количество сотрудников, которые могут/а главное ХОТЯТ понимать что они делает достаточно мало. И все они занимают какие-то руководящие должности. А вот люди, которые делают рутинные операции не будут задумываться на д проблемами выскакивающих сообщений! Ну такова жизнь! Может где-то и есть идеальные кладовщики, но их очень мало!
Видимо, у нас кладовщики идеальны
А по сути - надо требовать от пользователей чтение сообщений. Надо! Я лично требую всегда. Потому что информация в инфолог выводится не просто так.

P.S. Я на клиенте работаю, если что.
__________________
С уважением,
Вячеслав
За это сообщение автора поблагодарили: lev (2).
Старый 14.01.2012, 02:24   #18  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
В общем-то уже почти все по делу ответили, но ведь это не повод...
Цитата:
Сообщение от ta_and Посмотреть сообщение
Не смог сдержать крик души. На каждом проекте - одно и то же! Серые кнопки... серые кнопки... серые кнопки. И на каждом проекте приходится с ними долго и упорно сражаться и жить...
Я не призываю полностью отказаться от серых кнопок. Я не призываю переписать уже имеющийся функционал. Давайте хоть новую функциональность проектировать грамотно?
Давайте просто разделять презентационную и бизнес-логику. Очевидно, доступность выполнения тех или иных действий, затрагивающих бизнес-логику, должна и проверяться обязательно на уровне бизнес-логики. А дальше - дело техники вывести эти проверки наружу так, чтобы их можно было дергать загодя, без активизации тех или иных действий, и использовать результаты в презентационной логике: для засеривания ли кнопок, для отключения ли возможности править/удалять записи на уровне датасорсов формы, для отключения ли доступности на редактирование полей таблиц - это уже вторично, это просто удобства для пользователей. Крик души топик-стартера, по-моему, связан скорее с тем, что зачастую бизнес-логика смешивается с презентационной, и кроме засеренности кнопки или отключения редактирования на датасорсе ничто не препятствует изменению данных или выполнению тех или иных действий. Вот тут я солидарен: давайте функциональность проектировать и реализовывать грамотно.
Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
Главное преимущество программного вывода сообщения над статической пусть и контекстной справкой в том, что в рантайм есть возможность определить истинную причину недоступности той или иной операции и включить в текст сообщения конкретные значения обрабатываемых величин. Хочется иметь возможность "спросить" у заблокированного контрола причину по которой он заблокирован.
Это все здорово, но дюже дорого в поддержке. Если бы речь шла о тиражируемом решении, используемом миллионами клиентов (как винды или офис), тогда это бы окупилось, а когда делается модифа под одного клиента, такой "сервис" никто не купит.
Вообще же, если скатиться к саморекламе я что-то подобное пытался реализовать во Вспомогательных классах проверки условий и утверждений. С момента публикации практически во все методы DEV_Check был добавлен опциональный параметр - выводить ли сообщения или просто возвращать true/false, за счет которого удалось реализовать нечто подобное. Другое дело, что касается это лишь модификаций, реализованных с использованием соотв. классов, т.е. это совсем "нестандарт". И опять же, это все не бесплатно: я как-то оптимизировал с Trace Parcer'ом производительность одного класса (импорт из csv-файла ), и выяснилось, что отчасти в низкой скорости работы виновен указанный класс: за счет кэширования результатов некоторых специфичных проверок удалось ощутимо повысить производительность.
Цитата:
Сообщение от kashperuk Посмотреть сообщение
Я не дочитал, но в общем случае, я полностью согласен. На самом деле, в NAV вроде даже делали прототип, который делал как раз оповещение, если нельзя, с детальной причиной.
Думаю, в АХ это тоже когда-то появится.
О-о-о, да-а-а!!! Благими намерениями, как говорится... Вот с 4-ки появилась интеграция с ETW, но попробуйте просто разрешить трассировку Х++ в настройках рабочего АОСа, на который ходят 70-150 пользователей, и получите +35..40% загрузки процессоров - постоянно! Т.е. просто за саму возможность, если ее тупо держать "под боком" всегда включенной, вы будете расплачиваться вот такими вот тормозами. Возможно, это просто косяк реализации, но он уже показателен: ничто не дается бесплатно. Может, разработчики ядра виндов и вылизали интеграцию различных приложений и служб с ETW до того, что дополнительная нагрузка не превышает декларируемых 4-5%, но пока это явно не про ядро Аксапты (сужу сугубо по 2009-й).
Цитата:
Сообщение от pitersky Посмотреть сообщение
зачем человека держать за дрессированную обезьяну? человек должен понимать смысл того, что он делает и почему он этого сделать не может. хотя бы на самом общем уровне.
К сожалению, склонен согласиться с egorych: очень мало таких людей, которым это надо, большей части совершенно не интересны сообщения в инфологе, покуда кнопки нажимаются и что-то делается. Вот когда не делается, не получается - только тогда возникает понимание, что что-то не так. К сожалению, у людей зачастую мотивация (в утрированном, финансовом смысле) такова, что читать инфологи им некогда и незачем, главное - циферки нужные "повысить", потому что платят им за эти циферки, а не за понимание.
Цитата:
Сообщение от egorych Посмотреть сообщение
люди, которые делают рутинные операции не будут задумываться над проблемами выскакивающих сообщений! Ну такова жизнь!
Увы и ах...
Старый 16.01.2012, 10:06   #19  
pitersky is offline
pitersky
северный Будда
Аватар для pitersky
Ex AND Project
Соотечественники
 
1,486 / 408 (16) +++++++
Регистрация: 26.09.2007
Адрес: Солнечная система
Цитата:
Сообщение от gl00mie Посмотреть сообщение
большей части совершенно не интересны сообщения в инфологе, покуда кнопки нажимаются и что-то делается. Вот когда не делается, не получается - только тогда возникает понимание, что что-то не так. К сожалению, у людей зачастую мотивация (в утрированном, финансовом смысле) такова, что читать инфологи им некогда и незачем, главное - циферки нужные "повысить", потому что платят им за эти циферки, а не за понимание.Увы и ах...
не совсем понял возражение. вроде как автор как раз и говорит о ситуациях, когда что-то не так. И если при этом человек не хочет читать, что же именно не так, то я сильно сомневаюсь, что он сможет правильно повысить нужные циферки. Потому что тогда любой неразнесённый документ потребует времени на выяснение причины проблемы у отвечающих за Аксапту, а это заведомо медленнее.
Да и вообще - что значит "некогда и незачем"? я ещё не встречал ситуации, когда обработка с финальным (или ошибочным) инфологом не имела бы никакого отношения к обязанностям человека, её запустившего. А если имеет, значит это и есть его работа - читать такие сообщения и решать возникающие проблемы. либо самостоятельно, либо через непосредственного руководителя.
__________________
С уважением,
Вячеслав
За это сообщение автора поблагодарили: ta_and (4).
Старый 16.01.2012, 11:07   #20  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от pitersky Посмотреть сообщение
А если имеет, значит это и есть его работа - читать такие сообщения и решать возникающие проблемы. либо самостоятельно, либо через непосредственного руководителя.
Вашими бы устами да мед пить

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

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Как у кнопки динамически поменять DataSource ? Poleax DAX: Программирование 4 06.09.2010 17:45
TreeNode кнопки на форме -> ClassId класса кнопки Андрей К. DAX: Программирование 4 27.07.2010 10:01
Активация/деактивация кнопки ToolBara Kaermo DAX: Программирование 5 23.07.2009 16:39
Аксапта как фронт-офисное решение в рознице. vc DAX: Функционал 15 11.02.2008 10:42
как в табличном методе "узнать" о нажатии определенной кнопки на форме Zeppelin DAX: Программирование 12 08.11.2007 20:47
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра
Комбинированный вид Комбинированный вид

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 10:58.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.