Добрый день.
Столкнулся с проблемкой.. Разрабатывается ИС которая содержит несколько АРМ, ИС работает с БД. АРМы естественно что-то с этими данными делают.
Сегодня возник с программистом довольно жаркий спор по поводу интерфейса. Каюсь, сам виноват что не проработал этот момент в ТЗ.
Суть вопроса: есть форма с табличным представлением данных (по сути, это и весь АРМ….). Программист тупо эту форму и реализовал как просмотр так и редактирование, т.е. идет работа с гридом (таблицей/данными) напрямую.. Когда я указал что это не есть хорошо и надо добавить форму ввода, в ответ получил:
1. Я сделал как у них в журнале, как они привыкли ( в смысле пользователи работающие с бумажным журналом)
2. Нигде не встречал стандартов, описаний, рекомендаций и т.д. что это не есть хорошо..

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

П-Лstells2Суть вопроса: есть форма с табличным представлением данных (по сути, это и весь АРМ….). Программист тупо эту форму и реализовал как просмотр так и редактирование, т.е. идет работа с гридом (таблицей/данными) напрямую.
Убого. Неужели ваша модель данных (бизнес-объекта) столь проста, что позволяет втиснуть себя всю в одну плоскую таблицу ?
Эх.. ребята... Насколько проста модель если в ней более 300 таблиц и реализована большая часть логики средствами СУБД...
Суть не в том. Это одно из многих, маааленькое АРМ с немногими функциями, в модели ей отведено десяток таблиц (продуктив есно, НСИ в расчет не берется). И суть АРМа в простом учете прихода расхода металлолома (финансы отсутствуют).
В общем, меня больше интересовало не правильно это или нет (вот так, на живую с табличной формой работать пользователю) :), ибо насчет правильности можно долго спорить и я считаю вполне правильным разделять представление от редактирования/ввода данных.
Я просил, если кого не затруднит, дать ссылку(и) на книги, стандарты и т.д. где бы сей момент был озвучен (впрочем и подход проектирования GUI в целом и в контексте работы с БД в частности). Причем, я не прошу "дайте мне документ подтверждающий мою правоту".. :) Нет, но вот поискал и не нашел хоть что-то, а говорить от себя.. ну не все верят на слово. Да и не плохо бы, что бы программисты хоть немного подтянулись в этом вопросе (с образованием и с опытом хреново).
Если не сложно, и вдруг у кого то есть на примете название, ссылка и т.д. – буду признателен.

trdmГоните нафиг, такого специалиста. Если он с вами спорит, а не находит точки соприкосновения.
это не есть нормальная форма взаимоотношения заказчика и исполнителя.
^{вкусите множество сексуальных наслаждений с нашей новой платформой... (с) 1С. Ну вы поняли...}
:( Увы, я не заказчик.. и гнать то не выход - самому чтоли писать?

egorychзапретительный подход к непосредственному вводу данных в таблицу пользователем верен, скажем, отнюдь не всегда, вы и не нашли ссылок, книг и стандартов, подтверждающих его )))
Совершенно согласен - все в меру и к месту. Но, если есть "операция" фиксирования данных как операция рабочего места (не АРМ), и эти данные надо вводить в таблицу, в которой может быть допустим, нескольк млн. записей (понятно что используются процедуры и вьюшки и т.д.), то, я наверно склонюсь к решению что это должна быть именно форма ввода/коректировки данных. Ну и с другой стороны, чисто по эноргонимике.. Насколько в состоянии оператор объять мозгом массив хотя бы на 10 строк и 10 полей (это 1/4 формы)? При этом, это числовая информация...
Снижение ошибок ввода -
(например:И при этом, если этих операторов 2, один начал вводить и ему приспичило.. отлучился подощел второй и стал вводить свои данные.. и т.д.)
ну и т.д. в общем, если это табличка из 10 строк и данные статичны, то почему бы и не править в "живую".. Или я не прав?

звиняюсь за очепятки..