在2011年为Pluss研究网络监控工具时，两件事情一再打击我。第一个是可用工具的复杂性，第二个是由于这个丑陋的直接结果，在一个小的支持团队中工作，我最终必须成为解释这些工具的UI来解决什么根本的问题是。
也许丑陋的描述方式太强大了，我的意思是网络监控本来就很复杂，所以这些工具的UI也往往也是内在复杂的。您基本上可以收集有关网络中所有节点的尽可能多的数据，然后将所有数据都放在仪表盘上，然后尝试敲击布局，使其显示实际上对支持团队有用的信息。信息显示往往是信息捕获的第二个被深思熟虑的元素，我急于找到一个反过来建立的产品，用户界面第一，所以显示的信息实际上每天都是有用的，我们小团队中的任何人都可以阅读并采取行动的格式。
我的研究导致我到斯科特·巴恩斯博客帖子“ 用户故事管理 ”和他的真棒UI设计：
斯科特用这句话说：“ 软件应该反映我是谁，什么是上下文相关的，或者是同步的，以满足我的需求，而不必要求我适应它的需求。
这正是我对网络监控工具的感受。这些信息应该被分组，处理，然后以与内容相关的方式显示给观众的工作职能，而当时的总体趋势是显示一切，并让工程师诊断所有红灯和警告的根本原因。 UI。好吧，这有点不公平，即使在nagios中，你也可以创建更简化的仪表板，但是所有这些都需要多次点击才能深入到节点的底层源数据，一旦点击完成，你需要成为第三行工程师了解仪表板上“红灯”的根本原因。他们没有显示逻辑，或者可能需要大量事件的智能，并确定其根本原因，并将其显示在简单，优雅的用户界面上。
为了帮助向我的团队解释Scotts的想法，我带着他的用户界面，完全按照他的建议 - 使我的团队具有内在的相关性，帮助他们了解网络监控如何为我们找到。
可悲的是，尽管这对我们来说是正确的（我们甚至开始把它作为Silverlight中的一个工作模型），但时间和金钱却无法让我们用自己的自定义用户界面控制面板前进。我们坚持使用nagios /仙人掌和人类对其显示的数据的解释，因为这是“最快”，“最简单”和最低风险的方法。但是有一天，我希望所有的网络监控平台都是按照Scott的建议，从用户界面的角度出发，采用与内容相关的方式。