如何优化 J2EE struts 应用程序中的屏幕空间？
我正在开发一个旧的 J2EE struts 应用程序，它的 UI 设计非常糟糕。大多数页面都滥用了屏幕空间，例如下拉菜单、标签、文本框等之间的空间不均匀。页面上不同项目的对齐效率不高，导致空间浪费。有时用户被迫使用不必要的滚动条，我觉得这很烦人。我本来可以手动修复它，但这样的jsp大约有250个，一一修复它们将超出我的预期寿命。所以我想知道是否有其他方法可以解决这个可用性问题。我可以想到以下 2 个选项（如果这听起来完全荒谬，请不要恨我，你可以提出任何你认为相关的建议）
1）任何开源 API 来扫描我的 jsps 并给出我可以改进的建议？
2）我应该遵循什么可用性设计标准来改善用户体验？
任何帮助将不胜感激
I am working on a old J2EE struts app which has very bad UI design. Most of the pages are misusing the screen real estate like there are uneven spaces among dropdown, labels, text boxes etc. Alignment of different items on page is not very efficient leading to space wastage. And sometimes users are forced to use unnecessary scroll bars which I find very irritating. I could have fixed it manually but there are around 250 such jsps, fixing them one-by-one will exceed my life expectancy. So I am wondering if there is any other way to solve this usability problem. I can think of below 2 options (please don't hate me if it sound thoroughly ridiculous, you can suggest whatever you find relevant)
1) Any open source API to scan my jsps and give recommendations where I can make improvements ?
2) What usability design standard should I follow to improve user experience ?
Any help will highly appreciated
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
语义 HTML。真的，就是这样。这样，您只需一个 CSS 文件就可以控制一切。
Not that I am aware of. I myself just use the W3's online HTML and CSS validator whenever needed.
Semantic HTML. Really, that is it. This way you can control everything with just a CSS file.
不幸的是，正确对齐这些组件需要花费大量时间，如果您希望获得良好的布局，则必须手动完成。以前开发过这个的人也知道这需要多少时间，并决定不花时间正确布局字段。
您的这个问题可能更多地与需求有关，而不是与技术/开发有关，因此也许最好的办法是给最吱吱作响的轮子（有问题的用户）涂抹润滑脂，并将所有这些未来的变更请求视为工作保障。
Unfortunately, aligning these components correctly takes a lot of time, and must be done manually if you wish for a good layout. Whoever developed this before was also aware of how much time is needed for this, and decided not to take the time to properly layout fields.
This problem of yours probably has more to do with requirements than technology/development, so perhaps the best thing to do is apply grease to the squeakiest wheels (the users who are having problems), and consider all of these future change requests as job security.