LabVIEW 界面设计秘诀

First of all we’ll quickly define what we mean by UI and introduce some rules, or guidelines, that you should follow to help you create quality UIs. UI design principles are no different in LabVIEW as they are for any other programming language and there are many good resources available on the internet and in books; consequently we won’t spend too much of our time here today talking about generic UI principles. Topics such as how to choose nice colors or group like objects are important but since they are covered so well elsewhere I will leave those as a homework assignment and spend most of our time here showing you some techniques and features in LabVIEW which will allow you to create much better UIs without doing too much extra work.

Finally, since LabVIEW has such a strong community of developers I’ll leave with a URL where you can go and get some reusable UI components, as well as discuss and share your UI‐related questions.

UI stands for user interface. It is the way your applications user gives commands and receives feedback from your application.

For those of you who develop applications to sell, the UI is often the “cover” to your book –the crucial first impression. A good UI implies a thorough, professional development team whereas a sloppy UI can turn potential clients off.

A good UI makes the user’s job easier since they spend less time trying to figure out how to complete their task (which often translates to less questions for the developer). I bet you can name a few applications off the top of your head where an unintuitive UI makes using that application more difficult than it should be which translates into inefficiency, frustration and resentment from you, the user.

Your job as the UI developer is to predict the points of frustration and lay out an interface that helps the user get their job done. Getting the job done is most people’s primary concern.

The design of the user interface and the usability of the application are closely intertwined. Any visual element that doesn’t contribute in some way to the efficient completion of tasks in your application is in some ways superfluous “eye candy”. This isn’t necessarily bad but it certainly shouldn’t be where you spend most of your time.

Likewise, functionality or features that aren’t represented in the UI can only be considered background tasks since the user has no way of using that functionality.

Some general rules I suggest you keep in mind as you develop are 1. Don’t be innovative, 2. Less is more, and 3. Think about your user. I’m not saying that you should never break one of these rules, but if you do you should do so consciously and for good reason.

Let’s look a little deeper at each of these rules….