Цитата:
Сообщение от
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.