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 housecorresponds to a “Home” screen. Using these icons in your application lets theuser almost work on autopilot as their visual brain can recognize the button and not rely on reading every word./watch?v=2NdqXh67makHow to Add Decals to Buttons1.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 preserved4.Right click on the control and select Import Picture from Clipboard»Decal5.Click the wrench icon to change customize mode6.Move the decal or the text so they aren’t overlapping7.Save your custom controlReuse tip:If you give your customized control an icon and save it in <LabVIEW>\user.lib it will show up in the controls palette under User Controls.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./watch?v=NGeElmr1q2gThe 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./watch?v=rOUcBvyHj5EThe LabVIEW toolbar is for you, the LabVIEW developer. It includes all the debugging and editing tools you need to create your application. It is unlikely that your end user cares about these tools and worse yet, the extra buttons may distract and confuse your user. Hiding the toolbar while your application is running is generally a good idea once you know that the application is functioning correctly./watch?v=2CbKuBVGzo0The run‐time menu is the familiar File, Edit, etc menu you see at the top of most Windows applications. LabVIEW has a default run‐time menu with a large set of entries which may or may not be applicable to your user.LabVIEW allows you to easily edit the menu to contain as many or as few of the default options as you wish. You can also add your own menu items and use the event structure to handle the user’s selection./watch?v=wkpiAmHFddMYou can also customize the run‐time shortcut (right click) menus for any control by right‐clicking on the control and going to Advanced»Run‐Time Shortcut Menu»Edit.Grouping infrequently changed options or controls in a separate dialog is a quick, easy, and common way of freeing up space on the main display.Dialogs work best for “set‐and‐forget” type of options that you don’t expect people to regularly interact with or need to reference. They also work well for controls that require lots of contextual information to assist the user in making a decision./watch?v=L‐hNmzQ9tFcCompartmentalizing is a common organizational strategy that groups like objects in their own areas. Just like a workspace or a child’s bedroom ‐‐It’s much easier to keep places tidy if everything has it’s own place.Panes are areas of a front panel that are separated by splitters. By default, front panels start with just one big pane which works great for small, simple applications. For larger or more complex apps I like to separate the front panel into several panes for a few reasons: 1.Panes allow some parts of the front panel to remain in place while other parts scroll ormove.2.Panes can be fixed to either edge of the screen and can have a fixed width or share theavailable screen size proportionally. This makes it much easier to handle differentscreen sizes./watch?v=hZ180R7ADtoAnother advantage of panes is that since a splitter is a GObject we can change it’s position programmatically using VI Server. Using a button, event structure and property node we can give the user the ability to “hide” a panel completely and then bring it back with the click of a mouse.Another special‐use case for panes can be to create a persistent status bar. In the bottom left of your status bar add a string control and simply update the text contained in the status bar via local variable wherever you need to.This simple technique is one of the most effective ways of keeping your user informed as to what state your application is in or what task it is busy performing.Along the lines of keeping the user updated –LabVIEW lets you change the cursor to a busy cursor programmatically. The busy cursor is an OS‐wide UI element that most users are quite familiar with (it means –“wait, I’m trying to do something!”)./watch?v=_mosr‐oTgRMPutting everything together you have a few options for updating the user. Personally I think the best approach is to use all of them! I even include a progress bar if I know how long a given task will take.If you don’t update the cursor or inform the user in some other way you run the risk of your user thinking that clicking a button or performing some other action went unnoticed by your application. Impatient users have a tendency to re‐click or otherwise attempt to force some change (including the dreaded Ctrl‐Alt‐Delete) if they don’t think the application is responding. It is up to you to let them know that everything is OK and that the app is just busy.For really long tasks (longer than a couple of seconds) you might want to add a cancel capability if possible. You don’t want a mis‐click to tie up the application for a long time.The next application we will look at is for a small touch screen display. Here our primary concerns are the small screen size, the need to account for fingers rather than a much more precise mouse cursor and the possibility of glare or direct sunlight impairing the contrast of our display.Again, applying the rules really ensures we think about our requirements.First of all since we want simple, high contrast controls, that more resemble physical buttons the modern control style makes more sense than system in this case.Secondly since the screen real‐estate problem is probably our biggest challenge here. Lets spend some time looking at a creative solution.Tab controls are a common way of displaying multiple pages worth of information. The “tabs” at the top allow the user to see what displays are available and switch between them.Having switchable pages of displays is perfect for our use case since we have such a small screen. However the “tabs” themselves could be problematic since the touch screen might not be accurate enough to press in such small locations reliably.VI Server comes in very handy again here since we can hide the tabs and change the page programmatically.In the demo I use two tab controls. One to contain the sliding menu and one to contain the pages of controls/graphs etc.The sliding menu tab control only has one page and has the tabs hidden. The reason I use the tab control is that it is a convenient container that I can move programmatically.The other tab control has several pages which are changed using VI Server according to which button the user presses in the menu.This is the SubVI which does the sliding. In the demo I use it to move a tab control that contains all the menu buttons but it works with any type of front panel control.The basic premise of the VI is that in order to move an object from it’s initial position to a desired position it moves the object halfway and then iterates until the object gets to the desired location. This approach generates the natural sliding appearance where the object moves quickly at first and then slows down as it stops.Putting the tab control containers, move.vi and an event structure together you have all the elements of the sliding menu. When the menu button is clicked we slide the tab control to the visible position and store the old position in shift register. Then when the user makes a selection we slide the menu tab control back to it’s original position (storing the visible position in the shift register) and switch the main content tab control to the desired page.The last application we will look at today is an informative kiosk display. This type of application has a unique set of demands since there isn’t much user interaction –the primary concern is allowing a user to consume some important information with just a quick glance.We are assuming the information density is fairly low and an attractive appearance is an important consideration in order to attract attention.Just like your computer desktop background you can use an image as the background of your front panel. A well chosen background image can provide context (i.e. “I know this is the pond temperature monitoring VI because I can see the pond in the background”) or visual appeal.On the other hand –too complicated of a background image can be distracting and make important controls and data hard to read. There is rarely an absolute right or wrong in this regard but if you know what LabVIEW is capable of and keep the 3 rules in mind you are in a good place to make your own determination./watch?v=gxXJfonTlFcIn the demo you will see that I used a “busy” background image but still made the controls easy to read by including a semi‐transparent decoration with a nice gradient fill and drop shadows. LabVIEW currently doesn’t have these kind of effects built in but you can easily import images from other applications when you need them.This particular decoration I created in Microsoft PowerPoint and imported into LabVIEW as an image which sits on top of my background image./watch?v=gjYfqhlv2hQAnother default behavior that you may choose to override is the frame applied to all controls and indicators. For most applications the frame is beneficial to separate the controls contents from surrounding labels. The default behavior of white backgrounds for controls and gray backgrounds for indicators is another usability feature that subtly indicates to the user whether or not a given object accepts input or not.If you choose to go without these features you do have that ability. For this particular application we aren’t concerned about users becoming confused about controls vs indicators since it’s a read‐only application./watch?v=jgUB1oDmf‐4The weather icon indicator is a special case of the previous technique. By combining a transparent picture ring control with some transparent PNGs you can create some pretty powerful, nice looking graphics which will add some visual appeal to your application and also increase the usability of your UI by providing instantly recognizable icons for various states./watch?v=AmDLCsnOegwYou’ll also notice the gauge control in our demo doesn’t look anything like the default gauge control.Most of the default controls in LabVIEW can be customized by replacing most of the source imagery using the control editor. Since doing so requires a fair amount of artistic ability and knowledge of external images editors we aren’t going to cover exactly how to create your own controls in this presentation.This particular control is part of the Inspired Control Suite available for download from the community. In the community you can also find a tutorial explaining the details of how to create customized controls.。