Привет всем.
собственно, такой вот пока отстраненный от реальной задачи вопрос — давать или не давать пользователю возможность редактирования данных в гридах/таблицах?

Речь идет о гридах/сетках/таблицах, являющися отображением коллекций/списков неких сущностей (скажем — документы некоего типа), колонки которых являются отображением отдельных атрибутов этих сущностей (например, для документов, это может быть некая сумма или вид продукции, услуги).

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

Собственно, вопрос к usability-специалистам — вообще, правильно ли это??? С одной стороны — возможность быстро по контексу поправить некие атрибуты экономит время (и может быть это актуально когда речь идет о массовых операциях ввода/вывода), но с другой стороны, между атрибутами сущности могут существовать связи, когда значение одного атрибута зависит от другого...

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

Здравствуйте, DuШes, Вы писали:

DШ>Вообщем, интересуют чисто теоритические основы применения редактирования данных в сетке (речь не идет о базах данных, только о прикладном применении) и Ваши размышления на этот счет

Не отношу себя к специалистам по usability (я скорее, любитель), но выскажусь.

Как говорится, "it depends", т.е. зависит от ситуации.

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

2. Если свойств объекта не так много (например: ключ-значение), а самих объектов может быть очень много — грид с редактированием в ячейках также рулит.

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

Здравствуйте, DuШes, Вы писали:

DШ>Привет всем.
DШ>собственно, такой вот пока отстраненный от реальной задачи вопрос — давать или не давать пользователю возможность редактирования данных в гридах/таблицах?

Я конечно не специалист :-) но в общм соглашусь с предыдущим оратором. Изначальный вопрос аналогичен вопросу с таким же сабжем, но заданному на каком-нибудь женском форуме. Давать или не давать, очень сильно зависит от того, кому давать, и когда давать.

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

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

Здравствуйте, DuШes, Вы писали:

DШ>Привет всем.
DШ>собственно, такой вот пока отстраненный от реальной задачи вопрос — давать или не давать пользователю возможность редактирования данных в гридах/таблицах?

[skipped]

DШ>Собственно, вопрос к usability-специалистам — вообще, правильно ли это??? С одной стороны — возможность быстро по контексу поправить некие атрибуты экономит время (и может быть это актуально когда речь идет о массовых операциях ввода/вывода), но с другой стороны, между атрибутами сущности могут существовать связи, когда значение одного атрибута зависит от другого...

А если не давать редактировать в табце атрибуты со связями, а только простые атрибуты? И как вариант можно каким-нибудь способом показать связь сложного атрибута с теми от которых он зависит или которые от него зависят (граф отобразить или просто список).

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, DuШes, Вы писали:

DШ>>Привет всем.
DШ>>собственно, такой вот пока отстраненный от реальной задачи вопрос — давать или не давать пользователю возможность редактирования данных в гридах/таблицах?

А>[skipped]

DШ>>Собственно, вопрос к usability-специалистам — вообще, правильно ли это??? С одной стороны — возможность быстро по контексу поправить некие атрибуты экономит время (и может быть это актуально когда речь идет о массовых операциях ввода/вывода), но с другой стороны, между атрибутами сущности могут существовать связи, когда значение одного атрибута зависит от другого...

А>А если не давать редактировать в табце атрибуты со связями, а только простые атрибуты? И как вариант можно каким-нибудь способом показать связь сложного атрибута с теми от которых он зависит или которые от него зависят (граф отобразить или просто список).

к выделенному — даже не представляю как...

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

Здравствуйте, rlabs, Вы писали:

R>Здравствуйте, DuШes, Вы писали:

DШ>>Привет всем.
DШ>>собственно, такой вот пока отстраненный от реальной задачи вопрос — давать или не давать пользователю возможность редактирования данных в гридах/таблицах?

R>Я конечно не специалист но в общм соглашусь с предыдущим оратором. Изначальный вопрос аналогичен вопросу с таким же сабжем, но заданному на каком-нибудь женском форуме. Давать или не давать, очень сильно зависит от того, кому давать, и когда давать.

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

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

Здравствуйте, DuШes, Вы писали:

DШ>Согласен, просто в одном приложении такого рода ситуаций может быть много, скажем, при редактировании сущностей одного вида конечно легче и наверно лучше редактирование напрямую в самой сетке (скажем, прайс-лист, перечень услуг), и в том же приложении может быть редактирование, ввод новых счетов-фактур, договоров и так далее...Поэтому, хотелось бы выработать именно общий подход к редактированию — т.е. хочется уйти от варианта, что для такой сущности позволяем редактирование, для этой запрещаем, только через диалог ... Мне кажется, такая особенность поведения сетки будет лишний раз только напрягать пользователя...хотя, даже не знаю :xz:

Общий подход — это как "одеть всё страну в резиновые сапоги". Вроде и красиво, и по лужам можно, только зимой холодно, а летом жарковато.

Я не думаю что даже внутри одного приложения должен быть только один подход. То, что разные методы должны быть согласованы между собой — да, надо. А всё ж таки для разных задач — разный интерфейс. Возможен даже вариант, когда в одном месте, с одними и теми же данными, есть несколько интерфейсов — просто потому что разные пользователи выполняют разные задачи. Оператору надо данные побырому вбить, а какому-нить менеджеру или там директору надо один какой-то документик поглядеть и красиво распечатать.

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

Здравствуйте, DuШes, Вы писали:

DШ>Вообщем, интересуют чисто теоритические основы применения редактирования данных в сетке (речь не идет о базах данных, только о прикладном применении) и Ваши размышления на этот счет

Скажем так — тут нужен двойной подход
при выборе документов естественно нельзя редактировать его свойства через грид
1. как минимум потому что его могут захотеть редактировать два человека одновременно
2. как последний аргумент это что сама текущая выборка (сетка как угодно назовите) может основывается на некотором условии — например все выставленные но не оплаченные платежи — если я могу отредактировать платёж прямо тут (допустим что оплата это просто чекбокс) выставляю этот чекбокс — нажимаю ентер (чтобы сохранить) платёж должен сделать что ? пропасть ? нет — остатся ? тоже нет

ну а вот уже в документах — список телефона человека с указанием сотовый это или рабочий или ещё как
вот эти гриды (сетки как угодно) уже удобнее сразу редактировать