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….
My first rule is don’t be innovative.To illustrate this point think about a car interior. Everyone who knows how to drive a car is familiar with a steering wheel, two or three pedals, a gear stick of some kind, normally turn signal stalks etc. You don’t have to relearn how to drive a new car. The basic controls are the same as your old car (the radio or navigation probably isn’t –and for me that is often a point of frustration).
Chances are the program you are writing is not going to be the user’s first computer program. Therefore the user has some kind of pre‐learned notions of how to interact with applications. You should fit into those notions rather than forcing the user to learn your way of doing things. A good rule people working on Windows systems is “make your application behave like Microsoft Office” since so many people are familiar with Office. Practically this means using common designs for buttons, using icons people will recognize, putting menus in places people expect them etc.
Note that this rule doesn’t mean you can’t be a little creative. There is still space for customization and adding your own touches, just do so in a way that doesn’t impact the usability of your program.
Rule#2 Less is More.
Don’t clutter up the screen unnecessarily with obscure settings or controls. Hide things that are only used infrequently and give the user a way to bring them back when necessary.
Presenting the user with fewer options eliminates distractions and allows them to focus on whatever it is that they ought to be focusing on.
One company who is very good at applying this rule is Apple. Both the iPod and the iPhone have been huge successes, despite generally costing more, having fewer features and lower specs than competitors products. One of the big reasons for this success is Apple’s commitment to stripping out unnecessary options and making an attractive user experience that preserves the important core functionality with fewer distractions. The iPod with it’s wheel and the iPhone with it’s solitary button are simple, yet effective.
As a developer it’s easy to assume that everyone knows how your application works and how to complete tasks using it –and if you are the intended user that’s great. For those of us who have to develop applications for other people to use then we have to keep those other people in mind as we develop.
The first implication of this is helping a user who doesn’t know as much as you do. They might not intrinsically know what each button/control in your applications does (although they might if you follow rule #1). For those cases where you have a unique action in your application use contextual cues to teach your user. Tooltips and status bars are common techniques that allow users to get more information about what a button does before they click on it.
Once the user clicks on something they generally expect something to happen. If the task is particularly slow you need to update the user to let them know that your application is working correctly. Just because you know what should happen in a given situation doesn’t mean that your user does.
The second major implication of thinking about your user is thinking about how and where the program will be used. Will the user have a mouse or keyboard? If one is missing that has implications as to how you will get input from the user. Touch screens are becoming increasingly popular and have their own sets of requirements (such as larger buttons and not relying on mouseover effects). Is your application going to be used outdoors or on low color displays? If so you will want to pick color schemes that do not rely on the user being able to see subtle differences in contrast.
We’ll spend most of the rest of this presentation looking at three different UI scenarios and some techniques you can implement in LabVIEW to improve your applications.
The Windows Desktop App is used on a PC with a high‐resolution monitor, a keyboard and a mouse. The user spends a fair amount of time engrossed by the application and expects this application to sit alongside other applications that they have installed on their computer.
This is a very common scenario where users generally have a lot of established UI expectations that you should take advantage of. Luckily LabVIEW has a number of features that can help you do just that.
Before we dive into LabVIEW let’s review the rules and discuss how they apply to this scenario.
LabVIEW contains three different sets of controls. The “Modern” style is set as the default but you can change this preference in Tools?Options?Front Panel. Since I primarily develop for desktop applications I tend to set my default to be the System controls since they match the operating system that the application is being run on.
A quick and easy way to convey more meaning with your buttons is by adding decals.
People know that a floppy disk icon means save and a picture of a house
corresponds to a “Home” screen. Using these icons in your application lets the
user almost work on autopilot as their visual brain can recognize the button and not rely on reading every word.
https://www.wendangku.net/doc/bb5788918.html,/watch?v=2NdqXh67mak
How to Add Decals to Buttons
1.Drop a System OK Button on the front panel.
2.Right click on the control and select Advanced?Customize…
3.Edit?Import Picture to Clipboard and select your image ‐
?PNG files work best since transparency is preserved
4.Right click on the control and select Import Picture from Clipboard?Decal
5.Click the wrench icon to change customize mode
6.Move the decal or the text so they aren’t overlapping
7.Save your custom control
Reuse tip:
If you give your customized control an icon and save it in
Tooltips are the explanatory text that appears when the mouse hovers over a UI element for a few seconds. There is no better way to help and unsure user figure out exactly what a given button does by popping it up right as they hover over the button in a state of indecision.
LabVIEW has this capability built in for all controls.
https://www.wendangku.net/doc/bb5788918.html,/watch?v=NGeElmr1q2g
The default graphs in LabVIEW were designed to look similar to the physical instruments that virtual instruments often replace. Since we are developing for a different type of user –namely the desktop PC use case –we can change the color scheme to better fit the work environment and also help our user with their primary task.
In this application I am assuming that the user is trying to identify whether or not a given sine wave violates a simple limit test.
https://www.wendangku.net/doc/bb5788918.html,/watch?v=rOUcBvyHj5E