无法正确重新设计GUI以获得更好的用户体验 [英] Can't properly redesign GUI to get better user experience

问题描述

简介：



我是一位经验不足的软件开发人员，他的任务是实施信息系统我自己的。由于截止日期很短，我无法设计UI以为用户提供方便的体验。我也没有人求助，但已经设法以某种方式按时完成工作。由于目前只有一个用户使用该软件，因此没有任何投诉，但UI确实需要快速改进，这是该社区可以提供帮助的地方。



自这是我在这里针对这类问题发表的第一篇文章，我将尽可能详细地提供。随意编辑此帖子以符合本网站的标准。



如果重要，我使用 C ++ ， ResEdit [ ^ ]和纯WinAPI 创建UI。



同时考虑英语不是我的母语，所以我在前面为我所犯的任何拼写错误和语法错误道歉。



问题：



主要任务是优化桌面上的空间UI占用，并在数据输入期间提供愉快的用户体验。我尽力做到这一点，但我只是认为我的工作太可怕了。



相关信息：



这里 [ ^ ]是用于收集将输入数据库的数据的对话框。



重要提示：图片中的矩形不是UI的一部分，它们会添加到Paint中，因此我可以更轻松地解释我的问题。



橙色矩形中的控件的任务是收集有关建筑物位置的数据。 Combobox用于县，街道编号框，街道编号，x和y坐标。所有这些控件都做得很好，但在视觉上它们在我看来分组很糟糕，因为它们占用了太多空间而且在数据输入期间没有提供愉快的用户体验。



红色矩形中的控件用于收集有关建筑物的一般信息。在这里，我必须提到树视图控件可以很好地满足我的需求，我更愿意，如果我能保留它。组合框和编辑控件也可以很好地完成它们的工作，但是它们占用了太多空间并且组织严密，这在我看来会恶化用户体验。两个单选按钮应该代表是，否和未知。



到目前为止，对话框的左侧只是太大并且稍微不愉快，但它现在可能通过。我这方面的目标是优化空间并重新组织它们，用户可以通过输入数据轻松完成任务。



这是紫色矩形包围最有问题的部分。正确的蝙蝠侠我们可以看到两个有问题的部分用绿色矩形包围，查看图片 [ ^ ]。



这些控件组具有相同的任务，收集年度数据但是有两种不同的测量单位（让我们说左边的耗水量和右边的耗电量）。当其他所有内容都已完成时，在项目的最后添加了此功能。我没有时间考虑比现在更好的解决方案。因此，唯一不同的是应用程序处理底部编辑控件中输入的数据的方式。用户必须能够浏览，删除或编辑他输入的值。再次，由于紧迫的截止日期，我正在即兴创作，因为这个功能请求在最后一分钟发出。



这是另一个重要部分：一旦完成输入上述数据，用户必须通过选择左右单选按钮输入附加数据，这些按钮位于顶部的蓝色圆圈中（参见上面的第一张图片）。



让我们从更简单的情况开始，让我们假设用户点击了蓝色圆圈中的左侧单选按钮。 此处 [ ^ 是我们得到的：



重要提示：橙色矩形所包含的空格是为隐藏的控件保留的，当用户选择时这些控件将变为可见右单选按钮。这样只留下紫色矩形中的空间，因为在这两种情况下都使用绿色圆圈中的控件来简化我的编程工作。



紫色矩形中的编辑控件表示用户必须输入的一对数据。名字和姓氏之类的东西。用户输入的这些对的数量是未知的，所以我必须在绿色圆圈中添加控件以使用户能够添加（ + 按钮），删除（ - 按钮），编辑（ E 按钮）并浏览条目（箭头）。这对用户来说真的很不方便。



现在是时候用户选择合适的单选按钮了：



首先，用户必须输入两种类型的数据，查看图片 [ ^ ]。让我首先描述组合框在紫色矩形中的作用：用户可以从下拉列表中选择两个值中的一个，然后出现以下控件，请参阅图片 [ ^ ]。



组合框中第一个和第二个选择之间的唯一区别是额外的编辑控件，在上图中标有紫色矩形。再次注意，我使用相同的控件进行编辑，删除和浏览数据，就像之前的情况一样，用红色圆圈标记。编辑控件代表复杂的条目。名称，姓氏，出生日期......再次，条目数量未知，因此情况类似于用户选择左侧单选按钮时所描述的情况，只有数据更复杂。



其次，有橙色矩形，再次看这张图片 [ ^ ]。



矩形商店底部的控件单个条目，并没有太大的问题。也许它们也可以重新排序以提供更好的用户体验。然而，橙色矩形顶部的控件是个问题。根据组合框的选择，有两种情况。 首先 [ ^ ]类似于前面描述的那些。



再次，存储了一对值，我不知道它们的次数进入，我再次使用与以前相同的方法。 第二个 [ ^ ]只显示用户选择价值的组合框。



我努力解决这个问题：



要替换我的Frankenstein机制，我检查了<$> listview的 WinAPI 文档和代码示例控制但它不提供子项目编辑，也不允许组合框作为项目。



目前我正在尝试编写自己的网格控件我认为这对于这些案件来说是很好的解决方案。我需要做的就是添加对编辑，添加，查看和删除数据的支持。



只需单击列表视图行并按删除就可以了删除，这意味着我将失去一个不必要的按钮（图像中的 - 按钮），编辑也将被解决，因为用户可以双击单元格来编辑文本。同样，这将失去不必要的按钮（上图中的 E 按钮），并提供Windows精神的直观键盘解决方案。由于listview具有滚动条，因此查看所有数据非常简单。至于添加新数据，我仍然没有一个好主意，但我可以在用户按 + 之后编码数据输入...



这是我需要解决的关于我的UI的最重要的问题，我根本不适合这样的挑战:(



至于节省空间，我想到了使用制表符控制并将初始对话框中的三组数据移动到单独的选项卡中。灵感来自于阅读这篇MSDN文章。 [ ^ ]



虽然我有一个概念 - 将数据组移动到选项卡中并使用网格控件而不是我的弗兰肯斯坦机制 - 我仍然无法看到他的最终图片。



问题：



你能告诉我如何重新设计我的对话框及其对话框数据输入机制所以每次看一看时我都不会在房间里痛苦地尖叫一下吗？



我知道我可能会问一个很多，但请帮助我，因为我试图自己想象解决方案但是我没有达到目的。 :(



如果进一步信息是必需的，或者我需要清除我的帖子的某些部分，发表评论，我会尽快回复。



谢谢你你的帮助。



祝你好运。

INTRODUCTION:

I am inexperienced software developer who had a task to implement informational system all on my own. Since the deadline was short, I was unable to design UI to provide convenient experience for the user. I had no one to turn to for help either but have managed to somehow "finish" the job on time. Since only one user uses the software at the moment, there are no complaints, but UI really needs to be improved fast and this is where this community can help.

Since this is my first post here for this kind of a problem, I will provide as much detail as possible. Feel free to edit this post to fit the criteria of this site.

In case it is important, I have used C++, ResEdit[^] and pure WinAPI to create UI.

Also take into account that English is not my native, so I apologize in front for any spelling and grammar mistakes I make.

THE PROBLEM:

The main task is to optimize the space UI occupies on the desktop, and provide pleasant user experience during data entry. I gave my best to do this, but I just consider my work to be horrible.

RELEVANT INFORMATION:

Here[^] is the dialog box that was designed to collect data that will be entered into database.

IMPORTANT: Rectangles in the images are not the part of the UI, they are added in Paint, so I can have an easier job explaining my problem.

Controls in the orange rectangle have the task to collect the data about location of a building. Combobox is used for county, edit boxes for street, street number, x and y coordinate. All these controls are doing a fine job, but visually they are grouped badly in my opinion as they take up too much space and don’t offer pleasant user experience during data entry.

Controls in the red rectangle are used to collect general information about the building. Here I must mention that treeview control does an excellent job for my needs and I would prefer if I could keep it. Comboboxes and edit controls also do their job well, but they take up too much space and badly organized which worsens the user experience in my opinion.Two radio buttons should represent "Yes", "No" and "Unknown".

So far, "the left side" of the dialog box is just "too big" and slightly unpleasant to work with, but it might "pass" for now. My goal for this side would be to optimize space and to reorganize them in such a way user can have easier task with entering data.

It is the purple rectangle that encloses the most problematic part. Right "off the bat" we can see two problematic sections enclosed in green rectangles, see image[^].

These groups of controls have the same task, to collect yearly data but for two different units of measure ( let us say water consumption for the left side and electrical consumption for the right ). This feature was added at the very end of the project when everything else was already done. I had no time to think of a better solution than the current one. Therefore the only thing that is different is the way application treats the data entered in edit control at the bottom. User must be able to browse, delete or edit the values he entered. Again, I was improvising with this design due to tight deadline and since this feature request came in the last minute.

Here comes another important part: once finishing entering the above described data, user must enter additional data by choosing between left and right radio button, which are in the blue circle at the top ( see the first image above ).

Let us start with the easier case, let us assume user clicked the left radio button in the blue circle. Here[^] is what we get:

IMPORTANT NOTE: The space enclosed in orange rectangle is reserved for hidden controls that will become visible when user chooses right radio button. This leaves only the space in the purple rectangle to work with, because controls in the green circle are used in both cases to ease my programming work.

Edit controls in purple rectangle represent a pair of data user must enter. Something like name and last name. The number of these pairs user enters is unknown so I had to add controls in the green circle to enable user to add ( + button ), delete ( - button ) , edit ( E button ) and browse through entries ( arrows ). This is really inconvenient for the user.

Now is the time to cover the case when user chooses right radio button:

First, there are two types of data user must enter, see image[^]. Let me first describe the role of the combobox in the purple rectangle: User can chose one of the two values from the droplist, and then the following controls appear, see image[^].

The only difference between first and second choice from the combobox is the extra edit control, marked with the purple rectangle in the image above. Notice again that I am using the same controls for edit, delete, and browsing through data as in previous case, which is marked in red circle. Edit controls are representing complex entry. Something like name, last name, date of birth… Again, the number of entries is unknown, so the situation is similar to the one described when user chooses left radio button, only the data is more complex.

Second, there is the orange rectangle, again see this picture[^].

Controls at the bottom of the rectangle store single entries and are not much of a problem. Perhaps they too can be reordered to provide better user experience. The controls at the top of the orange rectangle are the problem though. Depending on the choice from combobox, there are two cases. First[^] is similar to the ones described earlier.

Again, a pair of values is stored, I don’t know the number of times they will be entered, and again I use the same approach as before. Second[^] simply shows combobox from which user chooses the value.

MY EFFORTS TO SOLVE THIS:

To substitute my "Frankenstein mechanism", I checked WinAPI documentation and code examples for listview control but it doesn’t offer subitem editing and doesn’t allow combobox to be an item.

Currently I am trying to code my own grid control as I believe this would be excellent solution for these cases. All I need to do then is to add support for editing, adding, viewing and deleting the data.

Simply clicking on the listview row and pressing delete would do the trick for deleting, which means I would lose one needless button ( the – button in the images ), and edit would be solved as well since user could double click the cell to edit the text. Again, this would lose unnecessary button ( E button in the above images ) and provide intuitive keyboard solution in the spirit of Windows. Seeing all the data is easy as listview has scrollbars. As for adding new data, I still haven’t got a good idea but I could code data entry to start after user presses + for example...

This is the most important problem I need to solve about my UI and I am simply not a match for such a challenge :(

As for conserving space, I got an idea to use tab control and move the three groups of data in the initial dialog box into separate tabs. The inspiration came after reading this MSDN article.[^]

Although I have a concept – moving groups of data into tabs and using grid control instead of my "Frankenstein mechanism" – I still can’t "see he final picture".

QUESTIONS:

Can you advise me how to redesign my dialog box and its data entry mechanics so I don’t scream around in pain around the room each time I take a look at it?

I know I might be asking a lot, but please help me as I have tried to visualize the solution myself but just am not up to it. :(

If further info is required, or I need to clear some part of my post, leave a comment and I will reply as soon as possible.

Thank you for your help.

Best regards.

推荐答案

如你所知，我几乎无法为它设计一切你，但我会试着给你一些想法，这些想法不够全面。



对我来说，看起来你的主要问题是代表选择树这使得一些控制与某些状态子集相关并且与其他状态无关。要处理它，您试图使控件属性动态依赖于其他属性，例如，使它们隐藏或显示。显然，您无法看到整个画面并想象您的工作流程。另外，我可以添加许多其他属性。例如，如果在某个控件中更改选择，并且该控件变得不可访问，然后再次可访问，则先前的选择应该是正确的。此外，你显然有使用空间的问题。这是另一个问题，但是应该在第二步中结合第一个问题来解决。这就是我设法概括你的问题的方法。如果我没有覆盖某些东西，我们可以稍后讨论;现在，让我们关注主要内容。



首先，您需要创建设计工作流程。你能做什么？我建议这样的事情：

• 我想你已经掌握了数据结构的所有细节。你需要检查它，看看取决于什么;在您的情况下，您需要特别注意主 - 细节关系。
• 分析由应用程序问题定义但未由数据结构定义的约束。在这里，您需要分析如果选择X，Y是不相关的等情况。
• 然后，您需要将数据结构制作到视图结构中。基本上，您需要根据以上所有内容确定需要显示的位置。
• 定义主要布局。准备好稍后更改它，因此使用可维护良好的原型设计/开发技术。
• 确定要使用的控件。
• 在窗口中平衡内容。请记住，空的空间几乎和占用的地方一样重要。

As you understand, I hardly can design it all for you, but I'll try to give you some ideas, which cannot be comprehensive.

To me, it looks like your main problem is to represent the tree of choices which makes some controls relevant for some subset of states and irrelevant to others. To handle it, you are trying to make control properties dynamically dependent on others, say, make them hidden or showing. Apparently, you have trouble seeing the whole picture and picturing your workflow. Additionally, I can add a number of other properties. For example, if you change selection in some control, and that control becomes inaccessible and then accessible again, the previous selection should be correct. Also, you apparently have the problem of using the space. This is another problem, but it should be solved on the second step, in connection with the first problem. This is how I managed to generalize your problems. If I'm not covering something, we can discuss is later; for now, let's focus on main things.

First of all, you need to create your design workflow. What can you do? I would suggest something like that:

• I guess you already have all the detail of your data structure. You need to review it, to see what depends on what; in your case, you need to pay special attention for the master-detail relationships.
• Analyze the constraints defined by the application problem but not defined by the data structure. Here, you need to analyze such cases as "if X is selected, Y is irrelevant", and the like.
• Then you need to make the data structure onto your view structure. Basically, you need to decide what would you need to show where, taking into account all of the above.
• Define primary layout. Be ready to change it later, so use well-maintainable techniques of prototyping/development.
• Decide on the controls to be used.
• Balance content in the window. Remember that empty space is nearly as important as the occupied place.

1. 我称之为一个屏幕总是足够的原则。即使在实践中这并非如此（因此很多人希望拥有更大甚至更大的屏幕），你无法做任何事情。假设一个模型的客户获得完美尺寸的显示器是最有成效的。这个人一次只能在屏幕上看到。如果您的数据呈现需要更多，则需要隐藏一些数据。请记住：您隐藏所有这些数据并不是因为您在屏幕上没有更多空间，而是因为客户并不想真正看到这一切。
2. 控件不应该被隐藏/显示，它们应该重叠的。这很难解释没有一个例子，但让我们来看看你在Гидротермална和Литогеотермална之间的选择。如果我没有太多错误，你想要显示一些控件如果选择了一个单选按钮，而另一个控件是另一个控件被选中。 （如果没有，我想你正试图在其他地方做这件事;纠正我）。你打算做什么？
   
   
   
   如果你隐藏一件并展示另一件，你将获得丑陋的空地。如果你移动一些内容来填补空白区域，那就更糟了。这与我将在另一点讨论的另一个原则有关，但也理解这一点：用户不希望在没有直接命令的情况下移动任何东西 - 这不是街机！
   
   
   
   因此，您需要将不同的面板重叠在另一个面板上。这个是正常的。这样做有不同的功能风格。
3. 以预期的方式使用标准控件。用户在选择单选按钮时会有什么期望？几乎没有：单选按钮应该形成一个独特的组（非常重要的是它与其他内容的视觉分离），应该选择此按钮，所有其他按钮都不被选中。您还可以在此事件上启用/禁用某些内容，最少更改某些颜色等，但不应移动/显示/隐藏任何内容。用户希望单选按钮只是一个单选按钮。因此，单选按钮不太适合于切换上面提到的内容。什么是合适的？我会在下面提出一些建议。
这并不意味着你根本不应该使用非标准行为。有时你应该，但那时控制应该是非标准的。一个例子：我曾经创造过一些视觉上类似于飞机舵控制的控制装置。用户一开始并不知道这是什么，但它与一些复杂的运动控制或监控有关，比如3-6个自由度;所以用户仔细尝试并看到它确实控制了动作。这与你的案件有什么关系？我看到一张地图作为背景。是的，你应该摆脱它（请看我对这个问题的评论），但如果这是功能性的呢？然后它可能需要3D控制（X，Y，缩放）。如果是这样，请查看Google地图控件。 用户应该得到可能确认一个人直观期望的内容。




4. 尝试创建非线性编辑。我借鉴了视频编辑领域的想法。它只是意味着用户应该能够随时修改数据的任何方面，而无需任何预定义的顺序。当我们谈论显示/隐藏某些控件时，这意味着这可能无法一步完成。您将需要步骤：选择选项或导航到不同的视图，然后更改控制状态 - 两个步骤，但不多。这与下一个项目有关。
5. 单窗口UI是最好的。正如所有这些原则一样，这一原则有许多例外情况。但是，您可能需要非线性编辑。如果将它全部放在一个主窗口中，它的效果最好。所有其他窗口应该是儿童，然后您可以快速切换它们。这也与单屏原理＃1有关。我不是指一些不计数的模态（弹出式）窗口，但即使它们应该受到限制。如果窗口处于模态状态，则在关闭之前不能更改任何其他内容。
   
   
   
   你的照片显示你计划在几个单独的窗户上。更好地重新思考它。
6. 让我们回到隐藏/显示部分UI。另一个想法是：滚动只能是最后的手段。更确切地说，这个原则仅适用于您的情况，但对于其他一些情况，滚动是最好的，特别是对于流文档。可以滚动文本或混合内容文档，调查，数据库，但不能控制某些选项和配置的窗口。
7. 视觉上分离控制的逻辑组并观看矩形区域的边缘。但是，要非常小心线条。通常，只有在具有不同功能的情况下才允许自己添加任何图形元素。视觉分离的最佳设备是空白空间。

1. The principle I call "one screen is always enough". Even if in practice this is not exactly so (so many people want to have bigger and even bigger screen), you cannot do anything with that. It's most productive to assume some model of a customer who obtained the monitor of a perfect size. This person needs to see only on screen at a time. If presentation of your data needs more, you need to hide some data. Remember: you are hiding all this data not because you have no more room on screen, but because customer does not really want to see it all.
2. Controls should not be hidden/shown, they should overlap. This is harder to explain not having an example, but let's look at your choice between "Гидротермална" and "Литогеотермална". If I'm not much mistaken, you want to show some controls if one radio button is selected, and some other control is another one is selected. (If not, I think you are trying to do it somewhere else; correct me). What are you going to do?
   
   If you hide one piece and show another one, you will get ugly empty space. If you move some content to fill in empty space, it will be even worse. This is related to another principle I'll discuss in another point, but also understand this: the user don't want anything to move without one's direct order — this is not arcade!
   
   Therefore, you will need to have different panels overlapping one over another one. This is normal. There are different functional styles of doing so.
3. Use standard controls in an expected way. What would a user expect on selection of a radio button? Almost nothing: radio buttons should form a distinct group (very important its visual separation from other content), this button should be selected, all other one unselected. You can also enable/disable something on this event, minimally change some colors, etc., but you should not move/show/hide anything. The user expects a radio button to be just a radio button. Therefore, radio buttons are not very suitable for switching the content, panels mentioned above. What is suitable? I'll suggest something below.
It does not mean that you should not use non-standard behavior at all. Sometimes you should, but then the control should be non-standard. One example: I once created some control visually resembling an aircraft's rudder control. The user doesn't know what is that at first, but it is associated with some complex motion control or monitoring, say, with 3-6 degrees of freedom; so the user tries it carefully and see that it really controls the motion. How is that related to your case? I saw a map as a background. Yes, you should get rid of it (please see my comment to the question), but what if this is something functional? Then it is something which may need 3D control (X, Y, zoom). If so, look, say, at Google Maps controls. The user should get something which is likely to confirm one's intuitive expectations.


4. Try to create a "non-linear editor". I borrowed the idea from the field of video editing. It simply means that the user should be able to modify any aspect of the data at any time, without any predefined order. As we are talking about showing/hiding some controls, it means that this might be impossible to do in one step. You will need to steps: chose option or navigate to a different view and then change the control state — two steps, but no more. This is related to the next item.
5. Single-window UI is the best. This principle, as all of them, has a number of exclusions. However, you probably want "non-linear" editing. It works the best if you put it all in one main window. All other windows should be children, then you can quickly switch them. This is also related to the single-screen principle #1. I don't mean some modal (pop-up) windows, which don't count, but even they should be limited. If a window in in modal state, you cannot change anything else until it is closed.
   
   You pictures suggest that you plan on several separate windows. Better rethink it.
6. Let's go back to hiding/showing parts of the UI. Another idea is: "scrolling can only be the last resort". More exactly, this principle is good just for your case, but for some other cases scrolling is the best, in particular, for flow documents. An text or mixed-content document can be scrolled, a survey, a database, but not the window controlling some options and configurations.
7. Visually separate logical groups of control and watch the edges of rectangular areas. However, be very careful with lines. Generally, you should allow yourself to add any graphical element only if it carry distinct function. The best device for visual separation is empty space.

现在，是时候考虑一​​些控制了。正如我所说，你应该重叠你无法同时显示的控件（面板）。我会告诉你两个最简单的设计。第一个是选项卡控件。每个点击页面都扮演一组控件的角色，这些控件转到背景或前景。所有标签页重叠，使用窗口上的相同空间。这是你的单选按钮，标签控件的那些标签的自然替代品。



第二种设计是你自己需要开发的东西：左边的树形视图（在西方文化中），右边是一组重叠的面板。树视图显示右侧显示的视图层次结构。选择树视图项时，右侧会显示一个或另一个面板。现在，一个实用的建议：如果你只有一个级别的层次结构该怎么办。列表框？没有！仍然是一个级别的树视图。 （您需要禁用虚线和其他不需要的元素。）为什么？有几个原因：树视图是Windows的新控件，质量更好，但使用起来几乎一样容易。更重要的是，您很有可能最终想要添加一个或两个级别的层次结构;什么，取代整个控制？不，最好从树视图开始。



还有什么？ （哦，不幸的是，如果我想要全面的话，我将永远不会停止写作......）

我已经告诉过你，没有背景，也没有全部。一般来说，良好的UI设计不应该炫耀，它看起来应该很好，很容易。没有原始主义的朴素。没有目的，没有一个细节。适度均衡的颜色和字体。小心，不要扯掉顾客的眼睛。



我承诺参考的手册实际上不是参考（但是它的名字是围绕手册这个词的文字游戏，但是对设计有一套无序的想法。无论如何，非常有用。你想试一试吗？好吧，您可以尝试： http://www.artlebedev.ru/kovodstvo/sections [ ^ ]。



给予一些想法，请看我的翻译只有一件，在这里：帮助我选择一个更好的最后一年项目 [ ^ ]。

-SA

Now, it's time to consider some control. As I said, you should overlap controls (panels) which you cannot show at the same time. I'll tell you two the very simplest designs doing exactly that. First one is the tab control. Each tap page plays the role of a group of controls which goes to background or foreground. All tab pages overlap, using the same space on your window. This is the natural alternative to your radio buttons, those tabs of a tab control.

The second design is something which you would need to develop yourself: tree view on left (in Western culture), a set of overlapping panels on right. Tree view shows the hierarchy of views shown on right. As you select a tree view item, one or another panel is shown on right. Now, one practical recommendation: what to do if you have only one level of hierarchy. List box? No! Still a tree view of one level. (You will need to disable dotted lines and other unwanted elements.) Why? There are several reasons: Tree view is newer control of Windows, it is better in quality, but nearly as easy in use. More importantly, you have big chances that eventually you will want to add one or two levels of hierarchy; and what, replace the whole control? No, better start with a tree view.

What else? (Oh, unfortunately, I'll never stop writing if I try to be comprehensive…)
I already told you, no background, no ALL-CAPS. Generally, good UI design should not be show-off, it should look nice and easy. Simplicity without primitivism. Not a single detail without purpose. Modest balanced colors and fonts. Be careful, don't rip out the customer's eye.

The "manual" I promised to reference is actually not a reference (but its name is a word play around the word "manual") but a unordered set of thoughts on design. Anyway, very useful. You wanted to give it a shot? Well, you can try: http://www.artlebedev.ru/kovodstvo/sections[^].

To give some idea, please see my translation of just one piece, here: Help Me to Choose A Better Final year Project[^].

—SA

这篇关于无法正确重新设计GUI以获得更好的用户体验的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！