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

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

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

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

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

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

_модstells21. Я сделал как у них в журнале, как они привыкли ( в смысле пользователи работающие с бумажным журналом)

Автоматизировать бумажный журнал ? Без вставки, удаления, корректировки и записи только последовательно ? Ну ну
:) Задачи конечно бывают разные... но не в этом случае. Но в общем, я крайне против перевода счетов на калькулятор. Тем более, это не переход со "старой" системы на "новую".. Это фактически новая, впервые создаваемая система. И потому, никто ни к чему не привык.
Есть простой принцип (ИМХО из опыта): Если программисты хреновые - грузим БД логикой по полной, оставляя программисту минимум напряжения мозга.. Иначе, база может быть проще.
У нас первый вариант :(
Конечно, первично - прототипом представления информации (и её ввода) является бумажный журнал. Но, если есть БД, и эта БД нормально организована то, понятно что существуют справочники, зависимости и т.д.
То, что есть в 1С не совсем табличная форма.. Хотя, и там как правило, используются формы.
Я согласен, что система, и приложения в частности, не должны усложняться.
Не хочу не кого задеть.. но честно говоря ERP система основанная на XLS файлах.. немного смущает :)
-------------------------
Как я и говорил, тема "форма или таблица" не так однозначна.. судя по постам :)
Я делаю вывод - международного или еще какого либо стандарта нет. Есть корпоративные, и знания (возможно убеждения) полученные в ВУЗах, курсах и опыте, а так же, различных не официальных источниках как то книги, чьи-то изыскания в этой области и рекомендации . Вот последнее меня и интересует.

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

Ребята, коллеги, меня не надо убеждать.. :)
Я совершенно с вами согласен.
И я не вчера закончил ВУЗ.. т.е. не настолько прямолинеен.
Имеется, как мне кажется достаточный, многолетний опыт программиста-разработчика.
И когда я планирую интерфейс, то естественно учитываются многие факторы, как то:
Функционал,
Удобство,
«интуитивность»,
Информативность
Минимизация нагрузки на оператора по вводу/корректировки данных
Цветовая схема
Расположение элементов
Минимизация возможных ошибок ввода/корректировки
«Привычность» (общепринятый GUI (на примере Windows), сложивщийся механизм работы пользователя (выполнение своих операций, возможно не автоматизированных).
Целевое назначение
Ну и т.д…..
хотя проще сказать можно: учитывается эргономика, функционал …. :)
И это все реализовать - отдельная головная боль.. Думаю, с этим наверно многие могут согласиться.
Но есть обратная сторона – когда все же требуется реализовать логику приложения…
А тут уж приходится искать компромисс, ну а кто сказал что сложный по сути продукт должен быть «для домохозяек»? (известного персонажа в расчет не берем).
И пожалуй, мне гораздо важней, как тут верно заметили, что бы система не была навязана и не доставляла мучений, что бы она была нужна и естественно заменила устаревшую технологию..
Это насчет как оно должно быть :) (а как бывает – все мы знаем).
Просто, садится и писать «стандарт» с нуля – нет времени. Вот и хотелось ознакомится с источниками.. Я не помню авторов, а так сам бы нашел.

iscrafmstells2,
побродите по ссылкам ...
Спасибо, буду разбираться

Petro123программист прав. Не надо усложнять там, где аналитик не может объяснить "зачем".
В общем случае разработка нетабличной формы дольше табличной.
- если функциональное рабочее место требует табличных данных
- если табличные данные влезают по вертикали \ горизонтали (т.к. есть ещё "вертикальные гриды")
- если зависимости между данными просты

то разработка нетабличной формы может говорить о закостенелости мЫшления постановщика задачи.
Вы не совсем правы.. :)
Аналитик не настаивает на форме и не отрицает таблицу..
В данном случае, табличная форма выполняет роль просмотра, т.к. в ней должны отображаться данные не тоько из одной таблицы а так же, отображаться данные полученные системной из внежних источником (контролеры). Следовательно, коль ввод и корректировка данных ведется посредством процедур (ну а как иначе в этом случае) то использовать форму ввода пожалуй единственный выход. К тому же, обеспечить минимизацию ошибок ввода можно. Ну и.. мы выносим операцию ввода/корректировки в отдельный функционал что и следует логике.
Простой пример:
Вы – напарник коллеги в смене, перед Вами рабочее место где на ¼ экрана сетка с массивом числовых данных, часть из них может обновиться автоматически.
Настал момент и надо ввести данные. Коллега начал вводить от отвлекся, отошел. Вам приспичило откорректировать другие данные – Вы начинаете редактировать «свои» данные, сохраняете. Да, система что-то там вроде как говорила.. А в это время, ваши данные ложатся «на стол» диспетчеру который должен принять решение. Решение основано на тех данных что предоставил ваш АРМ (точнее, тех данных, что возможно отредактированы или внесены вашим АРМом)…
Вопрос, насколько будет удобно работать за таким АРМом? К тому же, ввод/корректировка данных есть единичная операция, выполняемая пару раз в смену (не суть, но это не потоковый ввод). Просто, сегодня программист, за неимением опыта, еще не представляет тех нюансов с которыми столкнется, даже в плане программирования. Несмотря на то, что казалось бы табличная форма проще – это обманчиво. Так как требуется обеспечить контроль ввода, указания ошибки и т.д. Реализовать это в gride (C#) несколько сложней, чем в модальной форме.
В общем, понятно что можно сделать всё абсолютно.. и я не спорю. Можно сделать режим представления и редактирования как угодно, все зависит от квалификации программиста (и согласитесь, как следствие – человеко-часов).
Я так же не думаю, что стоит забывать или отказываться от «старых» систем, те технологии не ориентировались на монстрообразные компьютеры и полностью просчитывались исходя из требований «оператор-машина», и весьма не плохо проработанные. Все надо в меру… :)

stells2
Я так же не думаю, что стоит забывать или отказываться от «старых» систем
следует читеть как что не стоит забывать

iscrafmstells2,
На ровном месте столько проблем...
да нет никаких проблем. :) Всё решилось само собой, и человек сам решил что форма ввода в данном случае более подходит.. Решилось как только приложение попало в "работу"..
Эх.. Глядя на посты (в том числе и мои), все о чем угодно только не по сути.. Видать это всегда так :)
---------------------------
немного заинтересовало "выбрать нормальную среду.." что имелось ввиду?
У нас нормальная среда - VS, система - asm/(c/c++ - *nix)/java. СУБД - Oracle.
Клиенты на C#. Или, имелось ввиду что-то иное? Нет, WEB технологии не используются.

спасибо всем, приятно что столько людей готовы пообщаться... :)

iscrafm
думал у Вас проблемы с реализацией нормальной работы в гриде. Если все разрешилось, то хорошо.
Да есть немного.. к топику это конечно не относится..
Просто, я лично не большой специалист по C#.. На Delphi реализовать то, что порой "не так просто" делают коллеги на С# для меня легко.. Но, среда выбрана какой выбрана.. "Минус" в том, что половина людей в этом самом C# не доки.. Следовательно, человек пытается решить поставленную задачу обходя то, что надо бы сделать но что он пока не может.. :( отсюда и возможные "сложности"..
Я уж внес послабления - если человек способен более продуктивно реализовать на Delphi - то пусть это там и делает (просто, время оно почему то пролетает быстро). Но, люди всеже решили идти с боем (я о той части, которые имеют мало опыта в C#)... Может это и к лучшему...

_мод
Еще как зависит - юзер должен понимать, когда его изменения будут зафиксированы.
+1
я сторонник того, что человек должен осознавать ЧТО он делает, тупо надоедать с меседжами "вы уверены..." конечно не стоит, но явно реализовать операцию как таковую наверно стоит.
если допустить, что оператор в банке делает проводку не посредством транзакционной формы, а виде редактирования сплошной таблицы.. ну пофик, туда мильёон, сюда.. ошиблась, блин..