重新设计复杂 UI 的技术
我相信你们都见过它们。 业务线 UI 具有以下逻辑：“选择 ComboA 时，根据该选择查询值，并填充文本框 B”，或“按下 ButtonC 时，禁用文本框 C 和 D”，等等。当您可以对上述逻辑进行多种排列时，情况会变得特别糟糕。
如果有机会重新设计这些可爱的屏幕之一，您会如何处理？ 你会在 UI 前面放一个向导吗？ 您会保留单屏范例，但使用其他模式来使 UI 状态的逻辑可维护吗？ 您将使用什么流程来确定如何理想地呈现和实施这一点？
我并不认为这对响应很重要，但我目前面临的正是这个“机会”，它是一个 ASP.NET 网页，它使用 javascript 来响应用户的选择、禁用控件并进行 ajax 调用以获取额外的信息。数据。
I'm sure you've all seen them. Line of Business UIs that have logic such as: "When ComboA is selected, query for values based on that selection, and populate Textbox B", or "When ButtonC is pressed, disable Textboxes C and D", and on and on ... it gets particularly bad when you can have multiple permutations of the logic above.
If presented with the chance to redesign one of these lovely screens, how would you approach it? would you put a wizard in front of the UI? would you keep the single screen paradigm but use some other pattern to make the logic of the UI state maintainable? what would be the process you use to determine how this would ideally be presented and implemented?
Not that I think this should matter for the responses, but I am currently presented with just this "opportunity", and it's an ASP.NET web page that uses javascript to respond to the user's choices, disable controls, and make ajax calls for additional data.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可能需要考虑的是，其中一些依赖项是否并不意味着虽然看起来相似并提供相同的功能，但这些元素应该拆分到多个相似但实际上不同的页面上。 有人可能会将它们分组到页面上，因为它们有足够的相似之处。
如果您可以尝试将问题视为根本没有实现，那么如果您现在必须实现它，您将如何构建用户界面。 如果差异太大并且现有用户会遇到重大问题，您可能不得不做出妥协。 但正如 Elie 所说，从用户的角度来看。 他们是必须与您的产品配合使用的人。
Something you might want to look at is whether some of those dependencies don't imply that while looking similar and serving the same functions these elements should be split out over multiple pages that are similar but actually different. Someone maybe grouped these onto on page because there were enough similarities.
If you can try looking at the problem as if it were not implemented at all, how would you structure the user interface if you had to implement it now. If it is too radically different and existing users would have major problems, you might have to compromise. But as Elie said look at it from the users view. They are the ones that have to work with your product.
我会在一个对象上对整个 UI 的状态进行建模。 该对象应该跟踪每个 UI 对象应处于的状态，包括组合框的选项列表（当然还包括选择哪个选项）。
这意味着，拥有一个状态对象，您就可以正确地重新绘制整个屏幕，而不会在 UI 上陷入损坏状态。 当然，每次发生任何变化时都刷新所有组件并不是正确的方法，因此我会在状态对象中每个设置器的回调中刷新它们。 如果您愿意的话，这还允许您在同一状态下拥有两个 UI。
I would model the state of the whole UI on one object. That object should keep track of the state in which each UI object should be in, including the list of options of a combo box (and which option is selected of course).
That means that having one state object you can correctly re-draw the whole screen and not end up in broken states on the UI. Of course, refreshing all the components each time anything changes is not the way to go, so I would refresh them on callbacks from each of the setters in the state object. This would also allow you to have two UIs over the same state if you ever want that.
从 KISS 原则开始，然后从那里开始工作。 不要过度设计解决方案，并尝试从用户的角度思考问题。 您对良好布局的第一印象可能与您应该构建的内容很接近，因为良好的 UI 是直观的。
话虽这么说，单屏幕还是多屏幕、JavaScript 还是 AJAX，其实并不重要。 如果它看起来不错，很容易理解，并且在幕后有很好的注释并用清晰的代码编写，那么它就有效。 它应该是可维护的，因此目标是具有明确功能的模块化代码块。
Start with the KISS principle, and work from there. Don't over-engineer the solution, and try to think about the problem from the user's POV. Your first impression of what would make a good layout is probably close to what you should be building, as a good UI is intuitive.
That being said, single screen versus multiple screens, JavaScript or AJAX, it doesn't really matter. If it looks good, is easy to understand, and behind the scenes, is well commented and written with clear code, it works. It should be maintainable, so aim for modular code blocks with clear functionality.
我认为最重要的是用户体验，其次是代码的可维护性。 在网络上，我尝试尽可能减少往返次数，所以我不确定是否会采用向导方法，因为这会引导用户浏览多个页面或需要通过 AJAX 替换几乎整个页面（这似乎是错误的） 。 我通常与客户合作来获取他们所需的功能，尽管我的目标是功能，而不是实现。 我可能会模拟一些例子来向他们展示替代方案，或者只是在白板上手绘它们来给他们提供想法。 如果结果是大大改进的用户界面，我不介意在应用程序中做“困难”或“复杂”的事情。 当然，我会尽可能简单地做到这一点，并且肯定使用了良好的实践，即使是在 Javascript 中也是如此。
I think what is most important is the user experience and to a lesser extent the maintainability of the code. On the web I try to minimize the roundtrips as much as possible so I'm not sure that I would take a wizard approach since that would lead the user through multiple pages or require replacing nearly the entire page via AJAX (which just seems wrong). I typically work with my customers to capture the functionality that they require, though I aim at the functionality, not the implementation. I might mock up a few examples to show them alternatives or just hand draw them on a whiteboard to give them ideas. I don't mind doing "hard" or "complex" things in the app if the result is a much improved user interface. Of course, I make it as simple as I can and definitely use good practices, even in Javascript.