хорошие примеры графического дизайна для бизнес-ориентированных приложений с интенсивным вводом данных (crud)

<p>где я могу найти примеры очень хорошо созданного корпоративного программного обеспечения -<em>y</em>, которое имеет:</p><ul> <li>хорошее, последовательное использование сочетаний клавиш.</li> <li>хорошая клавиатура для навигации</li> <li>стандартизированная проверка формы</li> <li>стандартизированное использование экранов <em>lookup</em>/<em>search</em>. (пользователь запрашивает идентификатор клиента, не знает его, но может найти его во всплывающем окне, которое возвращает его)</li> <li>стандарты юзабилити/laf</li> </ul><p>было бы неплохо увидеть примеры, начиная от простых экранов crud и заканчивая очень сложными ориентированными на процессы графическими интерфейсами для таких приложений, как оценка crm/erp/financial/risk и т.д. в основном графические интерфейсы с большим количеством полей ввода, которые определяют определенный бизнес-процесс.</p>

<p>у меня нет примеров, на которые можно было бы указать. по правде говоря, многие из этих экранов могут быть трудно найти в интернете по той простой причине, что большинство из них имеют тенденцию быть "некрасивыми". такие экраны редко бывают симпатичными.</p><p>я могу предложить несколько советов из долгой истории работы с этими вещами.</p><ol> <li> <p><strong>согласованность.</strong> сделайте так, чтобы все "работало одинаково" и работало одинаково все время. по сути, вы должны иметь возможность сделать свою запись, глядя на форму, а не на экран. все эти вспышки, промежуточные итоги и цвета выглядят хорошо после ввода формы, но не во время самого ввода. там вам в основном нужны звуковые оповещения, чтобы они знали, "что-то не так" классический сценарий "ticky-ticky-ticky-ticky-beep-beep-beep-beep", когда пользователь обнаруживает, что он ввел поле, неправильное 4 поля назад. пользователи не совсем слепы, но они не будут смотреть на ваш экран. данные находятся на форме.</p> </li> <li> <p><strong>лучше работать модально, и остановить их ошибки, чем позволить им продолжать работать.</strong> для больших форм сканирование всей этой информации и поиск ошибок после факта очень трудны. остановите их, когда они ошибаются, чтобы они могли исправить это и двигаться вперед, а не возвращаться, чтобы исправить это в конце. чем больше в форме бизнес-правил, проверок и правоприменения, тем лучше. всплывающие окна, оповещения, сборщики, если это требует их внимания, модальные модальные. они не работают с глиной здесь. они не пишут великий американский роман и не моделируют мировую экономику.</p> </li> <li> <p><strong>суммируйте результаты для выборочных проверок.</strong> например, при вводе заказа они должны иметь возможность просмотреть итоговую сумму заказа и количество позиций, чтобы убедиться, что они получили заказ "правильно" в качестве сортировки. контрольной суммы вместо того, чтобы сканировать их поле ввода по полю. большинство рабочих процессов имеют неизбежную фазу перекрестной проверки, где они проходят свой ввод для проверки данных, но это должно быть после "необработанного ввода" данных. люди работают быстрее, когда они находятся в режиме "массового ввода", а не выборочной проверки каждого, каждый раз, когда они вводят его. это нарушает их ритм. облегчите обнаружение и исправление исключений после выполнения базовой проверки и ввода ключей. если некоторые поля важнее других (и вы знаете, какие из них), визуальное выделение их на экране и в бумажной форме творит чудеса.</p> <p>если формы и т.д. хорошо спроектированы (как компьютерные формы, так и бумажные формы ввода), в них трудно будет ввести ошибки (например, неправильный клиент, неправильный товар и т.д.). у вас может быть опечатка в некоторых заметках или специальных инструкциях, но не везде. если они неправильно используют элемент или сумму, шансы на то, что заказ не будет составлен должным образом, поэтому простая контрольная сумма поможет им поймать его.</p> </li> <li> <p>возвращаясь к "согласованности", <strong>убедитесь, что такие элементы, как сборщики и тому подобное, работают одинаково.</strong> постарайтесь свести к минимуму специальные функции, поскольку это упрощает обучение и позволяет пользователям просто "перетекать" в свои работа.</p> </li> <li> <p><strong>сочетания клавиш и навигация являются обязательным требованием, а не опцией.</strong> настоящей болезненной точкой здесь могут быть области подробностей (то есть структуры таблиц). вам может понадобиться ярлык для входа и выхода из таблицы. возможно, вы видели много примеров, когда вы можете "tab" в таблице, но не tab обратно. имейте специальную клавишу "мета-вкладка" для перемещения в разделы. требование мыши для навигации вне раздела - нет, нет.</p> </li> <li> <p><strong>имейте одну горячую клавишу для сборщиков.</strong> в идеале, им не придется использовать их слишком часто. может быть, для поиска клиентов, большинство других кодов они неизбежно запоминают, или они будут указаны в форме ввода. сделать сборщики фильтруемыми.</p> </li> <li> <p><strong>прокрутка - это дьявол. прокрутка - это зло. <em> нет прокрутки! </em></strong> пейджинг лучше, чем прокрутка, потому что "поля не двигаются", они всегда "в одном месте" на экране. как часто вы "прокручивали" и должны были искать, "чтобы начать" перед прокруткой, чтобы восстановить контекст. даже для списков выбора подкачка работает очень хорошо, потому что изменение страницы позволяет им знать, что они на самом деле "что-то сделали" визуально. много раз вы прокручивали строку и "блин, я правда?" прокрутка в одной строке может быть слишком тонкой. для больших форм ввода многостраничные ритмы длиннее, прокручивая трактаты каждый день недели. если ваши формы такие большие, убедитесь, что у вас есть горячая клавиша для перемещения вперед и назад по форме, и убедитесь, что на каждой странице есть некоторая контекстная информация (имя клиента, номер заказа, что угодно ... простой заголовок).</p> </li> <li> <p><strong>робастный запрос.</strong> "запрос по примеру", как известно, является одним из лучших механизмов (т. е. они заполняют его формой "что они знают" и формы возвращаются). людям нужно находить данные только по сумасшедшим критериям. если большинство полей могут быть запрошены, это позволяет им делать это, даже не догадываясь, что им будет или не нужно. в informix 4gl использовалась впечатляющая система qbe (<code>> 04/01/09</code> для дат после 1 апреля 2009 года, <code>12345|23456</code> для кодов элементов 12345 или 23456). хорошее выражение qbe, скорее всего, не будет проверяться в типичном поле, это особый случай. (вот почему вы редко видите qbe сегодня, это требует слишком много работы - но это он, так приятно.)</p> </li> <li> <p>помните, <strong>пользователи не знают <em>почему</em> или <em>как</em> они делают вещи, они только знают <em>что</em> делать.</strong> они знают <em> " когда я хочу сделать a, я нажимаю клавишу <kbd>y</kbd>"</em> они не знают, почему это y, где y находится, ключи x и z могут делать то же самое с а, потому что они сгруппированы вместе. нет, они не знают ваш командная таксономия. они не знают ваших абстракций. они знают, как сделать a, ударить <kbd>y</kbd>, хотите выделить слово? тип <kbd>ctrl</kbd>-<kbd>b</kbd>, может быть <kbd>ctrl</kbd>-<kbd>i</kbd> курсив word очевиден для вас из-за мнемоники, но не для большинства пользователей. может быть <kbd>ctrl</kbd>-<kbd>b</kbd> а также <kbd>ctrl</kbd>-<kbd>i</kbd> находятся в меню <code>format</code>, красиво сгруппированы. не имеет значения <kbd>ctrl</kbd>-<kbd>b</kbd> == жирный, как мне сделать курсив?</p> </li> </ol><p>недостатком этих интерфейсов является обучение. они проходят обучение для того, чтобы их использовали. но, по правде говоря, для любого достаточно сложного бизнеса пользователю все равно потребуется обучение гораздо большему, чем просто процесс ввода ключей. экран ввода не научит их бизнес-политикам, бизнес-правилам и т.д. вы можете применить их в приложении, но пользователю все равно придется знать их самостоятельно.</p><p>но это нормально, потому что в конечном итоге это просто более эффективно. здесь игра эффективно получает данные от пользователя и представляет их им в согласованном порядке. я не буду говорить "логический" путь, поскольку, хотя логика может быть логикой, она может не быть логикой пользователя. таким образом, вы можете быть логичным, если хотите, называйте это как хотите, но будьте последовательны со своими пользователями.</p><p>еще один анекдот, который мы использовали для 10 ключевых возвращаемых данных. это, как правило, просто списки чисел, такие как код товара и количество. для наших целей быстрее просто заставить пользователей вводить эти данные дважды подряд, чем что-либо еще. он улавливает опечатки, транспонирование и т.д. в сочетании с контрольными суммами пакетов позволяет выполнять набор намного быстрее. эти ребята смотрели на экраны только тогда, когда начинали, когда заканчивали, и если у них появлялась ошибка.</p><p>наконец, независимо от того, что ваши экраны и процедуры <em>изменятся</em>. какую бы форму вы не использовали в этом году, она изменится в следующем. это просто реальность, так что, к вашему сведению, будьте к этому готовы.</p><p>удачи с вашим проектом.</p>

<p>я фанат набора <a href="http://www.37signals.com/">http://www.37signals.com/</a> . я считаю, что их формы и графический интерфейс хорошо продуманы.</p>

<p>вы знаете, есть <a href="http://www.openerp.com/">openerp</a> , что вы можете получить программу, исходный код, документацию бесплатно.</p><p>ps: эта ссылка мне подходит, если вы не можете ее открыть, поищите openerp в google.</p>

<p>я использовал много - но трудно запомнить какое-то конкретное приложение, потому что действительно хорошие интерфейсы очень запрятаны.</p><p>я помню много плохих. тот, кто недоволен lotus notes, очевидно, никогда не использовал никаких приложений на основе форм sap или oracle.</p><p>для большей эффективности я бы посоветовал вам взглянуть на старую заявку на бронирование авиабилетов sabre. две строки текста без пробелов или других знаков препинания</p><p>первая линия рейса, вторая линия, детали платежа примерно такие, как если бы вы бронировали и оплачивали рейс:</p><pre><code>123109ba176y 276.00gbpam1122123412341234 </code></pre><p>туристические агенты пристрастились к нему и в течение многих лет отказывались принимать замену графического интерфейса super duper windows, запуская вместо этого эмулятор терминала зеленого экрана. я думаю, что смерть наступила только тогда, когда авиакомпании перешли на трехбуквенные коды и четырехзначные номера рейсов.</p>

<p>вот примеры того, что не нужно делать !: <a href="http://web.archive.org/web/20100715232035/https://stackoverflow.com/questions/238177/worst-ui-youve-ever-used">худший интерфейс, который вы когда-либо использовали</a> </p>

<p>я считаю <a href="http://www.enterprise-dashboard.com/">веб-сайт dashboard spy</a> одним из лучших для вдохновения.</p>

<p>вы действительно должны посетить <a href="http://homepage.mac.com/bradster/iarchitect/shame.htm">интерфейсный зал позора</a> , где вы найдете не только самые странные графические интерфейсы, которые когда-либо задумывались, но и возможные решения проблем юзабилити, которые они генерируют.</p>

<p>возможно, вам следует рассмотреть подход 37signals <a href="http://gettingreal.37signals.com">getting real</a> , учитывая, что в ваших приложениях есть много сложностей. getting real поможет вам разработать эффективный и полезный интерфейс, который будет радовать пользователей.</p>