适用于面向业务的大量数据输入 (CRUD) 应用程序的 GUI 设计的良好示例
我在哪里可以找到制作精良的企业软件的示例,这些软件具有:
- 良好、一致地使用键盘快捷键。
- 良好的键盘表单导航
- 标准化表单验证
- 查找/搜索屏幕的标准化使用。 (用户被要求提供客户端 ID,但不知道,但可以从返回它的弹出窗口中查找)
- 标准化可用性/LaF 约定 如果
能看到从简单的 CRUD 屏幕到非常复杂的面向流程的 GUI 等示例,我们会很高兴CRM/ERP/财务/风险评估等应用程序 基本上,GUI 具有大量定义某些业务流程的输入字段。
Where can I find examples of very well produced enterprise-y software that have:
- Good, consistent use of keyboard shortcuts.
- Good keyboard form navigation
- Standarized form validation
- Standarized use of lookup/search screens. (User gets asked for Client ID, doesn't know it but can look it up from a popup window that returns it)
- Standarized usability/LaF conventions
Would be nice to see samples ranging from simple CRUD screens to very complex process-oriented GUIs for applications like CRM/ERP/Financial/Risk assessment etc.
Basically GUIs with a high amount of entry fields that define certain business process.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(8)
我没有任何例子可以指出。 事实上,许多这样的屏幕可能很难在网上找到,因为大多数屏幕都“丑陋”。 这类屏幕很少很漂亮。
我可以根据长期使用这些东西的历史提供一些建议。
一致性。让一切“都以同样的方式工作”,并且始终以同样的方式工作。 基本上,您应该能够通过查看表单而不是屏幕来进行输入。 在输入表格后,所有这些闪烁、小计和颜色都很好,但在输入过程中则不然。 在那里,您基本上需要音频警报来让他们知道“出了问题”。 当用户发现他们输入了错误的 4 个字段时,出现了经典的“嘀嘀嘀嘀嘀嘀”场景。 用户并不是完全盲目,但他们不会看你的屏幕。 数据在表格上。
最好以模态方式工作,并在出现错误时停止它们,而不是让它们继续运行。对于大型表单,扫描所有信息并在事后查找错误非常困难。 当他们犯错时阻止他们,这样他们就可以修复它并继续前进,而不是最后回来修复它。 表单上的业务规则、验证和执行越多越好。 弹出窗口、警报、选择器,如果需要他们的注意,模态模态。 他们在这里不使用粘土。 他们不是在创作伟大的美国小说,也不是在为全球经济建模。
总结抽查结果。例如,输入订单时,他们应该能够查看订单总数和订单项计数,以查看是否“正确”获得了订单作为一种校验和,而不必逐个字段扫描其输入。 大多数工作流程都有一个不可避免的交叉检查阶段,在该阶段中,他们会通过输入来验证数据,但这应该是在数据的“原始键控”之后。 当人们处于“批量输入”模式时,他们的工作速度会更快,而不是每次输入时抽查每一项。这打破了他们的节奏。 完成基本验证和键入后,可以更轻松地检测和纠正异常。 如果某些字段比其他字段更重要(并且您知道那些字段是哪些),那么在屏幕和纸质表格上直观地突出显示它们会产生奇迹。
如果表格等设计得好(计算机表格和纸质输入表格),就很难输入错误(例如错误的客户或错误的项目等)。 您可能在某些注释或特殊说明中存在拼写错误,但在其他地方则没有那么多。 如果他们输错了某个项目或金额,订单很可能无法正确总计,因此简单的校验和将帮助他们捕获它。
回到“一致性”,确保像选择器之类的东西都以相同的方式运行。尝试将特殊功能保持在最低限度,因为它简化了培训并让用户“流动”投入到他们的工作中。
键盘快捷键和导航是必需的,而不是选项。这里真正的痛点可能是细节区域(即表格结构)。 您可能需要一个快捷方式来进入和退出表结构。 您可能已经见过很多示例,您可以通过“Tab”键进入表,但不能通过“Tab”键退出。 有一个专用的“元选项卡”键来移入和移出部分。 要求鼠标导航出某个部分是不行的。
为选择器提供一个热键。理想情况下,他们不必经常使用这些热键。 也许为了客户查找,他们不可避免地要记住大多数其他代码,或者他们将在报名表上键入。 使选择器可过滤。
滚动是魔鬼。 滚动是邪恶的。 没有滚动!分页比滚动更好,因为“字段不会移动”,它们总是在屏幕上“位于同一位置”。 您是否经常“滚动”并在滚动之前必须搜索以获取“您开始的位置”以重新获得上下文。 即使对于选择列表,分页也非常有效,因为页面更改让他们知道他们实际上在视觉上“做了一些事情”。 很多时候你滚动一行然后“天哪,我真的吗?” 单行滚动可能过于微妙。 对于大型报名表来说,多页的内容胜过一周中每一天的长篇滚动论文。 如果您的表单那么大,请确保您有一个热键可以在表单中向前和向后移动,并确保每个页面上都有一些上下文信息(客户名称、订单号等……简单的标题)。< /p>
强大的查询。众所周知,“通过示例查询”是最好的机制之一(即,他们填写“他们所知道的”表格,然后表格返回)。 人们需要通过疯狂的标准来查找数据,如果大多数字段都是可查询的,那么他们就可以做到这一点,而无需您再猜测他们将需要或不需要什么。 Informix 4GL 曾经拥有一个出色的 QBE 系统(
> 04/01/09
对于 2009 年 4 月 1 日之后的日期,12345|23456
对于项目代码 12345 或 23456)。 一个好的 QBE 表达式很可能不会在典型领域中验证,这是一种特殊情况。 (这就是为什么你今天很少看到 QBE,它需要太多的工作 - 但它真是太好了。)记住,用户不知道为什么或他们如何做事,他们只知道做什么。他们知道“当我想做 A 时,我按下键 Y“他们不知道为什么是Y,Y所在的位置,键X和Z可能会做与A类似的事情,因为它们被分组在一起。 不,他们不知道你的命令分类。 他们不知道你的抽象概念。 他们知道要做 A,点击 Y。 想要加粗某个词吗? 键入 Ctrl-B。 也许 Ctrl-I 将单词变为斜体对您来说是显而易见的,因为它有助于助记,但对大多数用户来说却不是这样。 也许 Ctrl-B 和 Ctrl-I 位于
Format
菜单上,很好地分组。 没关系。 Ctrl-B == 粗体,如何使用斜体?这些接口的缺点是培训。 他们确实接受了培训才能使用。 但事实上,对于任何相当复杂的业务,用户需要的培训远不仅仅是密钥过程。 入口屏幕不会教他们业务策略、业务规则等。您可以在应用程序中强制执行这些内容,但用户无论如何都需要自己了解它们。
但这没关系,因为从长远来看,它的效率更高。 这里的游戏是有效地从用户那里获取数据并以一致的方式呈现给他们。 我不会说“逻辑”方式,因为虽然逻辑可能是逻辑,但它可能不是用户逻辑。 因此,如果您愿意,您可以按自己的逻辑命名,但要与用户保持一致。
还有一个轶事,我们曾经用10个key返回数据。 这往往只是数字列表,例如商品代码和数量。 就我们的目的而言,简单地让用户连续两次键入此数据比其他任何方法都更快。 它可以捕获拼写错误、换位等。与批量校验和相结合可以使键入速度更快。 这些人只在开始时、完成时以及是否出现错误时查看屏幕。
最后,无论如何,您的屏幕和程序都会发生变化。 无论您今年使用哪种形式,明年都会改变。 这就是现实,所以,仅供参考,做好准备。
祝你的项目好运。
I don't have any examples to point to. In truth, many of these screens may be hard to find on the web for the simple fact that most of them tend to be "ugly". These kinds of screens are rarely pretty.
I can offer some tips, from long history working with these things.
Consistency. Make everything "work the same", and work the same all the time. Basically, you should be able to do your entry looking at the form, not the screen. All those flashes and subtotals and colors are nice after they keyed the form in, but not during entry itself. There you basically need audio alerts to let them know "something is wrong". The classic "ticky-ticky-ticky-ticky-beep-beep-beep-beep" scenario as the user discovers that they entered a field wrong 4 fields back. The users aren't quite blind, but they're not going to be looking at your screen. The data is on the form.
It's better to work modally, and STOP THEM for ERRORs than let them keep going. For large forms, scanning all of that information and looking for errors after the fact is very difficult. Stop them when they're wrong so they can fix it and move forward rather than coming back to fix it at the end. The more business rules and validation and enforcement you can have on the form, the better. Popups, alerts, pickers, if it needs their attention, modal modal modal. They're not working with clay here. They're not authoring the great american novel or modeling the global economy.
Summarize the results for spot checks. For example, keying in an order, they should be able to look at the order total and line item count to see if they got the order in "correctly" as a sort of checksum rather than having to scan their entry field by field. Most workflows have an inevitable cross check phase where they go through their entry to verify the data, but that should be after the "raw keying" of the data. People work faster when they're in a "bulk entry" mode rather than spot checking each one, each time they key it in. It's breaks their rhythm. Make detecting and correcting the exceptions easier after basic validation and keying is done. If some fields are more important than others (and you know which ones those are), visually highlighting them on the screen AND on the paper form works wonders.
If the forms and such are designed well (both the computer forms and the paper entry forms), errors should be difficult to enter (like the wrong customer, or wrong item, etc.). You might have a typo in some notes or special instructions, but, not so much everywhere else. If they miskey an item or amount, odds are the order won't total properly so the simple checksum will help them catch it.
Going back to "consistency", make sure things like pickers and such all operate the same. Try to keep the special functions to a minimum, as it simplifies training and lets users just "flow" in to their work.
Keyboard shortcuts and navigation are a requirement, not an option. A real pain point here can be detail areas (i.e. table structures). You may need a shortcut to enter and exit the table strcutures. You may have seen a lot of examples where you can "Tab" in to the table, but not tab back out. Have a dedicated "meta-tab" key to move in and out of sections. Requiring the mouse to navigate out of a section is a no no.
Have a single hot key for pickers. Ideally, they won't have to use these too often. Maybe for customer lookup, most of the other codes they're inevitably memorize or they'll be keyed on the entry form. Make the pickers filterable.
Scrolling is the devil. Scrolling is evil. No Scrolling! Paging better than scrolling because "fields don't move", they're always "in the same spot" on the screen. How often have you "scrolled" and had to search to pick up "where you started" before the scroll to regain context. Even for pick lists paging works very well because the page change lets them know they actually "did something" visually. Many times you scroll a row and "gee did I really?" Single line scrolling can be too subtle. For large entry forms, multi-pages beats long, scrolling treatises every day of the week. If your forms are that big, make sure you have a hot key to move forward and backwards through the form, and make sure there is some context information on each page (customer name, order number, whatever...simple header).
Robust querying. "Query by example" as it's known is one of the best mechanisms (i.e. they fill it the form "what they know" and forms come back). Folks need to find data by just crazy criteria, if most every field is queryable, this lets them do that without you second guessing what they will or won't need. Informix 4GL used to have a spectacular QBE system (
> 04/01/09
for dates after Apr 1 2009,12345|23456
for item codes 12345 or 23456). A good QBE expression will most likely not validate in a typical field, it's a special case. (Which is why you rarely see QBE today, it takes too much work -- but it is OH so nice.)Remember, users don't know WHY or HOW they do things, they only know WHAT to do. They know "when I want to do A, I hit key Y" they don't know WHY it's Y, where Y is located, the keys X an Z might do similar things to A because they're grouped together. No, they don't know your command taxonomy. They don't know your abstractions. They know to do A, hit Y. Want to Bold a word? Type Ctrl-B. Maybe Ctrl-I to italicize a word is obvious to you because of the mnemonic, it's not to most users. Maybe the Ctrl-B and Ctrl-I are on the
Format
menu, nicely grouped. Doesn't matter. Ctrl-B == Bold, how do I do Italics?The downside of these interfaces is training. They do take training in order for them to be used. But, in truth, for any reasonably complicated business, the user is going to need training on far more than just the keying process anyway. The entry screen isn't going to teach them the business policies, business rules, etc. You can enforce these in the application, but the user is going to need to know them on their own anyway.
But that's OK, because in the long run it's simply more efficient. The game here is getting the data from the user efficiently and presenting it to them in a consistent way. I won't say "logical" way, as, while logic may be logic, it may not be the users logic. So, you can be logical if you want, call it what you want, but be consistent to your users.
Another anecdote, we used to 10 key return data. This tended to be just lists of number, like an item code and a quantity. For our purposes it's faster to simply have the users key this data twice in a row than anything else. It catches typos, transpositions, etc. Combined with batch checksums makes the keying go that much faster. These guys only looked at the screens when they started, when they finished, and if they got an error.
Finally, no matter what, your screens and procedures WILL change. Whatever form you're using this year, will change next year. That's just reality, so, FYI, be ready for it.
Good luck with your project.
我是 http://www.37signals.com/ 套件的粉丝。 我发现他们的形式和 GUI 是经过深思熟虑的。
I am a fan of the http://www.37signals.com/ suite. I find their forms and GUI's to be well thought out.
你知道,有一个Openerp,你可以免费获得程序、源代码、文档。
ps:这个链接对我来说没问题,如果打不开,请在google中搜索openerp。
You know, there is Openerp that you can get program, source ,doc for free.
ps: this link is OK to me, if you cannot open it, search openerp in google.
我用过很多——但很难记住任何特定的应用程序,因为真正好的用户界面很容易被遗忘。
我记得很多不好的事情。 任何抱怨 Lotus Notes 的人显然从未使用过任何基于 SAP 或 ORACLE 表单的应用程序。
为了纯粹的效率,我建议您查看旧的 SABRE 航空公司预订应用程序。 两行文本,没有空格或其他标点符号
第一行航班第二行付款详细信息类似这样的内容将预订并支付航班费用:
旅行社对此上瘾,多年来拒绝接受超级骗子 Windows GUI 替代品启动绿色screen 终端模拟器代替。 我认为当航空公司改用三字母代码和四位数航班号时,它才彻底消亡。
I have used lots -- but its difficult to remeber any specific app as really good UIs are prety much forgetable.
I can remember lots of bad ones. Anyone who bitches about lotus notes has obviously never used any SAP or ORACLE forms based apps.
For sheer efficiency I would suggest you look at the old SABRE airline reservation application. Two lines of text no spaces or other punctuation
First line the flight second line payment details something like this would book and pay for a flight:
travel agents became addicated to it and for years refused to accept the super duper windows GUI replacement firing up the green screen terminal emulater instead. I think it only died the death when airlines switched to three letter codes and four digit flight numbers.
以下是不该做的事情的示例!: 你用过的最糟糕的用户界面
Here's examples of what not to do!: Worst UI You’ve Ever Used
我发现 Dashboard Spy 网站 是最好的灵感来源之一。
I find the Dashboard Spy website to be one of the best for inspiration.
你真的应该访问耻辱界面大厅,在那里你会发现没有不仅有有史以来最奇怪的 GUI,而且还有针对它们产生的可用性问题的可能解决方案。
You should really visit the Interface Hall of Shame, where you'll find not only the most bizarre GUIs ever conceived, but also possible solutions to the usability problems they generate.
鉴于您的应用程序似乎非常复杂,也许您应该考虑 37signals 的 Getting Real 方法。 Getting Real 将帮助您设计有效且有用的 UI,让用户满意。
Maybe you should consider 37signals' Getting Real approach given that there seems to be a lot of complexity in your apps. Getting Real will help you design effective and useful UI that keeps users happy.