Редактирование в сетках или в подробных формах - насколько умны конечные пользователи?

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

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

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

Придерживайтесь своего инстинкта. :)

По моему опыту, сетки с редактированием могут быть трудными как для программиста, так и для тестировщика и пользователя, потому что обычно триггером для проверки является событие kill focus. То есть пользователь отключает ячейку и останавливается с ошибкой в ​​этой ячейке, пока не исправит ее.

Это нормально? Зависит.

Если данные в каждой ячейке сетки можно проверить без ссылки на другие ячейки и особенно на другие строки, тогда, возможно, это нормально. Но если действительность одной ячейки зависит от значения в другой ячейке, то проверка, запускаемая фокусом уничтожения, может быть сложной. Ваш пользователь может оказаться в ситуации, когда ему придется поместить ЧТО-ТО в ячейку, чтобы иметь возможность покинуть эту ячейку и перейти к реальной ячейке, которая вызывает проблему.

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

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

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

Это в основном дело вкуса, но мои предпочтения соответствуют вашему разработчику (и ответу Кори, приведенному выше). Я предпочитаю модель только для чтения / редактирования, а не большую редактируемую сетку для большинства приложений. Но я много работаю в Excel, и меня бы убило, если бы мне приходилось открывать строку за раз. Разные цели! Если вы в первую очередь собираетесь выполнять большой объем редактирования с произвольным доступом, я бы остановился на сетке. Для всего остального (включая последовательный ввод) я бы использовал модель только для чтения с выдвижной формой. Различные приложения, над которыми я работал, показали, что пользователи могут работать с любым из них в соответствующем контексте.

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

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

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

По возможности редактируйте на месте в сетке и никогда не используйте диалоговое окно редактирования. Я не могу придумать преимущества наличия «режима редактирования», и он тратит время пользователей и усложняет приложение (с точки зрения пользователя). Наличие диалогового окна редактирования позволяет Сильнее изучить приложение, а не редактировать на месте, потому что пользователь должен научиться перемещаться между окнами дваи.

Как показывает опыт работы с Excel, Access и другими настольными приложениями, у пользователей нет проблем с редактированием сетки не больше, чем с редактированием чего-либо еще. У вас не должно возникнуть проблем, особенно если ваша сетка будет выглядеть как лист Excel, таблица или форма Access, а не как ваше типичное веб-приложение «Нажмите здесь, чтобы обновить».

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

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

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

Прямое манипулирование было доказанным принципом удобства использования с момента изобретения графического интерфейса пользователя. Уже давно было признано, что режимы создают проблемы с удобством использования. Настало время, когда веб-приложения достигли уровня удобства использования 1980-х годов.

Кстати, много пояснительного текста в окне (например, длинные ярлыки и несколько сообщений) является признаком проблемы с удобством использования, а не решением.

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