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

Question

Мне нравятся сетки - особенно крутые сторонние, такие как Devex, C1 и т. Д.

Наш программист не думает, что конечные пользователи могут справиться с ними - поэтому он всегда проектирует свои формы с сетками только для чтения (с классами только для чтения). Выбор для редактирования элемента в сетке открывает детальную форму, которая позволяет редактировать.

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

Answer 1

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

Answer 6

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

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

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