如何制作良好的报告界面
我有大量围绕学校、学生、教师、班级、地点等的相关数据，
我面临着客户提出的第四个挑战；他们想要获得关于所有事情的报告。这意味着他们希望能够以各种方式交叉引用数据点，而我认为我只是缺少编写一个漂亮的查询构建器。 ：/
这个堆栈问题旨在征求有关如何精美地构建报告界面的意见。
任何建议、参考、示例、jQ 插件等都会很棒。
谢谢你！
I have a ton of associated data revolving around a school, students, teachers, classes, locations, etc etc
I am faced with a challenge put fourth by my client; they want to have reports on everything. This means they want the ability to cross reference data points every which way and i think i'm just short of writing a pretty query builder. :/
This stack question is aimed at soliciting opinions on how to structure a reporting interface beautifully.
Any suggestions, references, examples, jQ plugins etc would be amazing.
Thank you!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我发现 Trac 的查询构建器对于它的用途来说相当可以接受。
但很可能你的客户并不想要一切，他们只是懒得考虑他们现在想要什么。您可以通过一起分析用例来帮助他们做出决定，并至少提出几种查询，其中只有少数部分可定制（在最坏的情况下），或者只是他们真正需要的一些预制查询。最好的。
I find the Trac's query builder rather acceptable for what it is meant to do.
But most probably your clients don't want everything, they are just too lazy to think about what they want now. You could help them decide by analyzing the use cases together, and come up at least with a few kinds of queries with just a few parts customizable -- in the worst case -- or just a few canned queries they really need -- in the best.
您可能应该安排与客户的会议，以确定他们需要做什么。这并不意味着让他们推测如果您的软件可以做所有事情、超级灵活但完全易于使用等等，那该多好……但是坐下来看看它们是什么现在正在做。我这样说是因为“哦，我希望能够将所有内容与其他内容交叉引用！”听起来有点太熟悉了，并且可能会导致平台内效应的丑陋情况。
我发现与客户一起快速制作纸质原型是探索可能想法的好方法，因为它将他们的注意力从“你能把这个按钮变成黄色吗？”转移开。向大局提出问题，让他们决定自己真正需要什么。另外，这样做的成本非常低。
除此之外，为了获得灵感，还有一些 UI 模式语言可以解决潜在的大量互连数据的处理问题。这些模式的优点在于，您通常能够使用这些模式向客户传达想法，因为结构良好的模式语言将指导非专家通过越来越详细的领域相关设计决策。
You should probably schedule a meeting with your client to determine what they need to do. This does not mean having them speculate about how great it would be if your software could do everything, was ultra-flexible yet totally easy to use, etc... but sit down and find out what they are doing right now. I'm saying this because that "oh, I'd like to be able to cross-reference everything with everything else!" sounds a bit too familiar, and might end in an ugly case of inner-platform effect.
I've found that rapid paper prototyping with the client is a great way to explore possible ideas, as it shifts their attention away from "can you make this button yellow?" issues to The Big Picture, to let them make up their minds what they actually need. Plus, it's ridiculously inexpensive to do.
Apart from that, for inspiration, there are UI pattern languages that address handling potentially large amounts of interconnected data. What's great about these is that you will often be able to use these patterns to communicate ideas to your client, since a well-structured pattern language will guide a non-expert through domain-relevant design decisions in increasing detail.
首先，我只能支持其他的声音：与客户一起解决他们真正需要的东西。一个很好的论点是“我可以做到，但这将花费您 X 千美元，每个用户将需要 Y 小时的培训，并且您需要每年 100,000K 美元的开发人员来维护它。”
（不幸的是，大多数客户此时更喜欢选择那些说“是的，可以做得更便宜！”的人）
只有第二，并且只有当客户说“是的，我们确实需要一切”时：
最有效的是列表/网格视图渐进式过滤。让用户直接使用结果，而不是构建 SQL 查询，然后运行它：例如，右键单击单元格，然后选择“限制为此值”可以添加
WHERE colN =约束。您可以通过
SELECT DISTINCT调用生成列建议 - 如果它返回的值少于（例如）20 个值，您可以为可能值的 OR 组合提供复选框。讨论一个优雅 UI 来解决大量剩余问题会很有趣：跨多列的 OR 条件、按多个列排序、分组……
First, I can only support the other voices: work out with the clients what they actually need. A good argument is "I can do, but it will cost you X thousand dollars, every user will need Y hours of training, and you'll need a $100.000K/year developer to maintain it."
(Unfortunately, most clients at that point prefer to pick the guy who says "yes, can do cheaper!")
Only second, and only if the client says "yes we do need everything":
What works well is a list/grid view progressive filtering. Instead of buildign the SQL query, then running it, let the user directly work with the results: e.g. right clicking a cell, and selecting "limit to this value" could add a
WHERE colN = <constant>constraint.You can generate suggestions for columns from
SELECT DISTINCTcalls - if it returns less than, say, 20 values, you can offer checkboxes for a OR combination of possible values.It would be interesting to discuss en elegant UI for the sea of remaining problems: OR'ed conditions across multiple columns, ordering by more than one column, grouping, ...