在与我们的客户服务部门的非正式对话中，他们表达了对我们基于网络的 CSA（客户服务应用程序）的不满。 在呼叫中心，每小时的通话量至关重要，大量时间浪费在鼠标移动、单击按钮、选择下拉列表中的值等上。客户服务总监渴望的就是回到过去使用键盘的美好时光。驱动的应用程序几乎没有视觉细节，只是向 CSR 提供数据并处理呼叫所必需的。
我不禁想起了我们都曾经使用过的绿屏应用程序（以及我们中经验更丰富的人曾经制作过的）。 这样的应用程序不仅会提高工作效率，而且对于销售代表来说使用起来更健康，因为他们必须冒着受伤的风险整天通过网络应用程序输入数据。
我想保持基于浏览器的部署的便利性并保留我们对 Microsoft 堆栈的现有投资，但如何提供这种键盘驱动的 超简单的绿屏概念到网络？
好的答案将链接到库、具有类似风格的其他 Web 应用程序、组织和优先考虑键盘快捷键数据的最佳实践（不是如何添加它们，而是如何存储和维护快捷键并自动解决冲突等。
编辑：接受的答案不会是关于如何在网络上进行 UI 的小型讲座，我不想点击任何链接、按钮或任何内容。
编辑2：此应用程序有 500 个用户，分布广泛 。在北美各地的呼叫中心，我无法重新训练他们使用 TAB 键
In informal conversations with our customer service department, they have expressed dissatisfaction with our web-based CSA (customer service application). In a callcenter, calls per hour are critical, and lots of time is wasted mousing around, clicking buttons, selecting values in dropdown lists, etc. What the dirrector of customer service has wistfully asked for is a return to the good old days of keyboard-driven applications with very little visual detail, just what's necessary to present data to the CSR and process the call.
I can't help but be reminded of the greenscreen apps we all used to use (and the more seasoned among us used to make). Not only would such an application be more productive, but healthier for the reps to use, as they must be risking injury doing data entry through a web app all day.
I'd like to keep the convenience of browser-based deployment and preserve our existing investment in the Microsoft stack, but how can I deliver this keyboard-driven ultra-simple greenscreen concept to the web?
Good answers will link to libraries, other web applications with a similar style, best practices for organizing and prioritizing keyboard shortcut data (not how to add them, but how to store and maintain the shortcuts and automatically resolve conflicts, etc.
EDIT: accepted answers will not be mini-lectures on how to do UI on the web. I do not want any links, buttons or anything to click on whatsoever.
EDIT2: this application has 500 users, spread out in call centers around North America. I cannot retrain them all to use the TAB key
发布评论
评论（5）
更严重的是，完全可以将键盘快捷键绑定到网络应用程序中的操作。
您可能会考虑教您的用户仅使用 Tab 键 - 这就是我填写大多数网络表单的方式。 按 Tab 键切换到选择列表，然后键入我尝试选择的选项的前几个字母。 如果页面没有在结构和选项卡索引方面做一些愚蠢的事情，我通常可以只用键盘填写大多数网络表单。
More seriously, it's entirely possible to bind keyboard shortcuts to actions in a web app.
You might consider teaching your users to just use the Tab key - that's how I fill out most web forms. Tab to a select list and type out the first few letters of the option I'm attempting to select. If the page doesn't do goofy things with structure and tabindexes, I can usually fill out most web forms with just the keyboard.
由于我必须随着时间的推移使用其中一些应用程序，因此我将作为用户提供反馈，FWIW，也许它可以帮助您帮助您的用户:-) 抱歉，它有点长，但这个主题相当贴近我的心 - 正如我让自己为这样一个系统设计了“改进的”界面原型（根据我们的计算，这可以节省大量资金并避免用户的不满），然后领导团队实现它。
我注意到很多 CRM 都有一个常见问题：屏幕上有 20 多个字段，其中通常使用 4-5 个字段来执行 90% 的操作。 但无论如何，我们都需要点击不必要的字段。
当然，我的这个假设可能是错误的（因为在我的例子中，有各种各样具有不同功能的用户使用该系统）。 但请尝试与用户坐下来，看看他们如何使用应用程序，看看是否可以优化 UI 方面的某些内容 - 或者，如果确实是不知道如何使用“TAB”的问题（他们每次确实需要使用这 20 个字段中的每一个） - 您将能够指导其中一些人并检查这是否足以满足他们 - 然后为整个组织推出培训。 确保您拥有直观的热键支持，并且如果列表包含 2000 个项目，用户无需手动滚动即可找到正确的项目，而是可以使用 FF 的功能通过键入文本开头来选择项目。
通过查看应用程序的使用模式，然后相应地优化 UI，您可能会学到很多东西。 如果您有多个使用该系统的组织职能部门，那么每个职能部门的“理想 UI”可能会有所不同，因此实施哪个以及是否实施的问题就成为业务决策。
还有一些其他对用户来说很重要的小细节 - 有时你认为他们的主要输入字段实际上并不是 - 他们有一个空的文本区域，占据了屏幕的一半，而他们必须输入将真正重要的数据放入角落某处的小文本字段中。 或者在他们的屏幕分辨率下，他们需要水平滚动（或者根本滚动）。
同样，与用户坐下来观察应该可以揭示这一点。
还有一个问题：“开发人员硬件速度太快”现象：许多网络开发人员倾向于使用高分辨率的大显示屏，以显示非常强大的 PC 的输出。 当结果以一年前笔记本电脑的 1024x768 分辨率显示在 CSR 笔记本电脑屏幕上时，布局和渲染性能看起来与预期有很大不同。 调，调，调。
最后，如果您的组织地理位置分散，始终使用最长延迟/最小带宽链路等效值进行测试。 这些问题在本地进行测试时不会出现，但在通过 WAN 使用系统时会增加很多烦恼。 简而言之 - 在对应用程序进行任何测试/开发时尝试使用最坏的情况 - 那么这会让你感到烦恼，你将优化它的使用 - 这样情况较好的用户就会高兴地跳过应用程序性能。
如果您使用“绿屏应用程序”，那么也许高级用户可以提供一个长文本输入字段，他们可以在其中以 CLI 类型的方式输入所有信息，然后点击“提交”或 ENTER 键（尽管这个设计决策不能掉以轻心，因为它需要大量工作）。 但每个人都需要意识到“绿屏”应用程序的学习曲线相当陡峭 - 这是从业务角度考虑的另一个因素，还有流失率等。问问老板典型的代理会呆多久在同一地点，如果他们需要 3 个月的时间才能全速运转，生产力会受到怎样的影响？ :) 这种平衡不是由程序员单独决定的，也不是由管理层单独决定的，而是需要共同努力。
最后，如果您有“高级用户”，您可能需要看看 conkeror 作为浏览器 - 虽然本身相当慢，但从仅键盘控制的角度来看，它看起来非常灵活。
As I had to use some of those apps over time, will give my feedback as a user, FWIW, and maybe it helps you to help your users :-) Sorry it's a bit long but the topic is rather close to my heart - as I had myself to prototype the "improved" interface for such a system (which, according to our calculations, saves very nontrivial amounts of money and avoids the user dissatisfaction) and then lead the team that implemented it.
There is one common issue that I noticed with quite a few of CRMs: there is 20+ fields on the screen, of which typically one uses 4-5 for performing of 90% of operations. But one needs to click through the unnecessary fields anyway.
I might be wrong with this assumption, of course (as in my case there was a wide variety of users with different functions using the system). But do try to sit down with the users and see how they are using the application and see if you can optimize something UI-wise - or, if really it's a matter of not knowing how to use "TAB" (and they really need to use each and every of those 20 fields each time) - you will be able to coach a few of them and check whether this is something sufficient for them - and then roll out the training for the entire organization. Ensure you have the intuitive hotkey support, and that if a list contains 2000 items, the users do not have to scroll it manually to find the right one, but rather can use FF's feature to select the item by typing the start of its text.
You might learn a lot by looking at the usage patterns of the application and then optimizing the UI accordingly. If you have multiple organizational functions that use the system - then the "ideal UI" for each of them might be different, so the question of which to implement, and if, becomes a business decision.
There are also some other little details that matter for the users - sometimes what you'd thought would be the main input field for them in reality is not - and they have an empty textarea eating up half of the screen, while they have to enter the really important data into a small text field somewhere in the corner. Or that in their screen resolution they need the horizontal scrolling (or, scrolling at all).
Again, sitting down with the users and observing should reveal this.
One more issue: "Too fast developer hardware" phenomenon: A lot of the web developers tend to use large displays with high resolution, showing the output of a very powerful PCs. When the result is shown on the CSR's laptop screen at 1024x768 of a year-old laptop, the layout looks quite different from what was anticipated, as well as the rendering performance. Tune, tune, tune.
And, finally - if your organization is geographically disperse, always test with the longest-latency/smallest bandwidth link equivalent. These issues are not seen when doing the testing locally, but add a lot of annoyance when using the system over the WAN. In short - try to use the worst-case scenario when doing any testing/development of your application - then this will become annoying to you and you will optimize its use - so then the users that are in better situation will jump in joy over the apps performance.
If you are in for the "green screen app" - then maybe for the power users provide a single long text input field where they could type all the information in the CLI-type fashion and just hit "submit" or the ENTER key (though this design decision is not something to be taken lightly as it is a lot of work). But everyone needs to realize that "green-screen" applications have a rather steep learning curve - this is another factor to consider from the business point of view, along with the attrition rate, etc. Ask the boss how long does the typical agent stay at the same place and how would the productivity be affected if they needed a 3-month term to come to full speed. :) There's a balance that is not decided by the programmers alone, nor by the management alone, but requires a joint effort.
And finally a side note in case you have "power users": you might want to take a look at conkeror as a browser - though fairly slow in itself, it looks quite flexible in what it can offer from the keyboard-only control perspective.
当其他人说重新设计的首要任务应该是与用户交谈/观察用户并看看他们在哪里遇到问题时，我非常同意他们的观点。 我认为，如果您找出用户最常见的任务和最常见的错误，并在现有用户界面的范围内简化这些任务和错误，您会看到更多的投资回报率。 我意识到这不是一件容易做到的事情，但如果你能成功，你将会拥有更快乐的用户（因为你已经解决了他们的工作流程问题）和更快乐的老板（因为你通过不使用在全新的 UI 上重新培训所有用户）。
看了大家的回答和评论后，我想谈谈其他一些事情：
我并不是想争论，但这听起来就像你已经下定决心，而没有考虑对用户的影响。 我可以立即看到这种方法的几个陷阱：
为您的用户提高工作效率。 为了
例如，平均年龄是多少
你的用户？ 大多数人 25 岁及
年轻人几乎没有
接触这些类型的 UI。
突然强加这样的
它们上的接口可能会导致
来自用户的重大强烈反对。 举个例子，看看发生了什么
当 Facebook 决定改变其
“流”概念的 UI - 巨大
引起用户的愤怒！
我认为这个论点实际上只是一个稻草人。 如果您要引入全新的用户界面，您将必须对用户进行培训。 实际上，应该假设对用户界面的任何更改都需要某种形式的培训。 像在 UI 中添加选项卡导航这样简单的事情实际上在培训部门中相对较小。 如果你这样做了，就很容易发送一封“用户界面中方便的新功能”电子邮件，或者更好的是，有某种“每日提示”（当然，用户可以关闭）告诉他们关于选项卡导航等很酷的省时功能。
我不能代表这里的其他发帖者发言，但我确实想说，我希望您不要认为我们在这里过于争论，因为这不是我们（好吧，我的）的意图。 相反，反应来自于我们听到了你的 UI 的想法，但不相信这对你的用户来说一定是最好的。 完全欢迎您说我错了，这才是您的用户将从中受益最大的； 但在您这样做之前，请记住，归根结底，您的用户才是最重要的，如果他们不购买您的新用户界面，那么没有人会购买。
I can't agree with the others more when they say the first priority of the redesign should be going and talking to / observing your users and see where they have problems. I think you would see far more ROI if you find out the most common tasks and the most common errors your users make and streamline those within the bounds of your existing UI. I realize this isn't an easy thing to do, but if you can pull it off you'll have much happier users (since you've solved their workflow issues) and much happier bosses (since you saved the company money by not having to re-train all the users on a completely new UI).
After reading everyone else's answers and comments, I wanted to address a few other things:
I don't mean to be argumentative, but this sounds like you've already made up your mind without having thought of the implications on the users. I can immediately see a couple pitfalls with this approach:
more productive for your users. For
example, what's the average age of
your users? Most people 25 and
younger have had little to no
exposure to these types of UIs.
Suddenly imposing this sort of
interface on them could cause a
major backlash from your users. As an example, look at what happened
when Facebook decided to change its
UI to the "stream" concept - huge
outrage from the users!
I think this argument is really just a strawman. If you are introducing a wholly new UI, you're going to have to train your users on it. Really, it should be assumed that any change to your UI will require training in one form or another. Something simple like adding tab-navigation to the UI is actually comparatively small in the training department. If you did this it would be very easy to send out a "handy new feature in the UI" email, or even better, have some sort of "tip of the day" (that users can toggle off, of course) which tells them about cool timesaving features like tab navigation.
I can't speak for the other posters here, but I did want to say that I hope you don't think we're being too argumentative here as that's not our (well OK, my) intent. Rather the reaction comes from us hearing the idea for your UI and not being convinced that it is necessarily the best thing for your users. You are fully welcome to say I'm wrong and that this is what your users will benefit most from; but before you do, just remember that at the end of the day it's your users who matter most and if they don't buy in to your new UI, no one will.
开发时实际上更多的是一种以键盘为中心的心态。 我尽可能多地使用键盘，我构建的应用程序往往表明这一点（因此我可以快速浏览我的用例）。
像正确设置 Tab 键顺序这样简单的事情可能就是您的应用程序所需要的（我想我不确定您是否可以在 ASP.NET 中设置它...）。 许多控件将自动完成其余操作。
It's really more of a keyboard-centric mentality when developing. I use the keyboard for as much as possible and the apps I build tend to show that (so I can quickly go through my use cases).
Something as simple as getting the tab order correct could be all your app needs (I guess I'm not sure if you can set this in ASP.NET...). A lot of controls will auto-complete for the rest.
我制作基于网络的企业社会责任应用程序。 您的经理忘记的是现在的应用程序要复杂得多。 与 15 年前相比，我们对销售代表的要求更高。 我们比以前收集了更多的信息并记录了更多的数据。
您应该专注于使 Web 应用程序表现得更好，而不是“绿屏”应用程序。 例如，当年份可以作为输入字段时，不要有年份下拉菜单。 确保制表符顺序正确且合理，您甚至可以在每个字段分组旁边放置一些小数字来指示制表符顺序。 将不同的屏幕/选项卡分配给 F 键并在屏幕上表示它们。
如果操作正确，您应该能够在没有鼠标的情况下使用您的网络应用程序，并且不会损失生产力。
利用 AJAX，这样到服务器的往返就不会改变光标的焦点。
在 CSR 应用程序上，您通常有多个默认值。 您应该为每个默认值分配一个按钮，并允许客户服务代表按 1 个按钮以获得他们想要的默认值。 这将减少点击和鼠标移动的次数。
也非常重要您需要与 CSR 坐在一起并观察他们一段时间，以了解他们如何使用该应用程序。 如果您还没有这样做，您可能会忽略一些简单的更改，而这些更改将大大提高他们的工作效率。
I make web based CSR apps. What your manager is forgetting is now the application is MUCH more complex. We are asking more from our reps than we did 15 years ago. We collect more information and record more data than before.
Instead of a "greenscreen" application, you should focus on making the web application behave better. For example,dont have a dropdown for year when it can be a input field. Make sure the taborder is correct and sane, you can even put little numbers next to each field grouping to indicate tab order. Assign different screens/tabs to F keys and denote them on the screen.
You should be able to use your web app without a mouse at all with no loss of productivity if done correctly.
Leverage the use of AJAX so a round trip to the server doesn't change the focus of their cursor.
On a CSR app, you often have several defaults. you should assign each default a button and allow the csr to push 1 button to get the default they want. this will reduce the amount of clicking and mousing around.
Also very important You need to sit with the CSR's and watch them for a while to get a feel for how they use the app. if you haven't done this, you are probably overlooking simple changes that will greatly enhance their productivity.