02-13-2009 03:54 PM
We continue development of a Xylophone Tuner with GUI concepts. When I design a GUI, I take a no compromises approach. I start with what I want and only modify if absolutely necessary. LabVIEW is pretty capable, so it usually is not necessary. A couple of other guidelines for general GUI development.
Now for the specific requirements for this GUI. First, a brain dump of what I would like. These are categorized into run–time and non–run–time. Non–run–time include configuration and debugging information.
02-13-2009 04:05 PM - edited 02-13-2009 04:06 PM
With that in mind, let’s see what we can do. It turns out to be pretty easy. Here are the screenshots. The main data is in an array with note, frequency, error in cents, and tuned/not tuned boolean (left to right) controls. It has an appearing/disappearing bottom section to show/hide the data plots. Configuration and calibration are separate dialogs. Both configuration and calibration will work while taking data so the user can visually see the effects of the changes. The plots will be automatically shown during configuration and calibration.
GUI Without Graphs Showing
GUI With Graphs Showing
These UI concepts are simply that. A first try at a UI which will satisfy the requirements in as simple a fashion as possible. The UI will undoubtedly be modified as the application is written and tested. In a formal design process, the UI concepts are usually tested with simulation code and modified as needed before starting the final code design.
Next time, we will start looking at design patterns for the final code. I have attached my current project (LabVIEW 8.5) for those who wish to look at the actual implementation.
02-13-2009 04:07 PM - edited 02-13-2009 04:08 PM
Calibration Dialog
Configuration Dialog
02-13-2009 04:07 PM
DFGray wrote:We continue development of a Xylophone Tuner with GUI concepts. When I design a GUI, I take a no compromises approach. I start with what I want and only modify if absolutely necessary. LabVIEW is pretty capable, so it usually is not necessary. A couple of other guidelines for general GUI development.
- The GUI should be designed by or with strong input from a domain expert. Programmers are usually not domain experts.
- The GUI should not reflect the internal data structure of the code. If anything the opposite is true.
- The GUI should not reflect business units of your company. Unfortunately, most companies fall into this trap because it is much easier.
...
Thank you Dr Gray!
Remarks and questions;
1) If you have to, get the end user to draw something on a napkin ath the very least.
2) Agreed!
3) What is a a "business unit"?
Ben
02-13-2009 04:16 PM
Ben,
A business unit is a logical division within a company. For example, a company which produces business software could have divisions responsible for producing vector graphics and bitmapped graphics. In their hypothetical software, they can ask the user to open a graphic file or they could make the user choose between opening a vector graphic or bitmap graphic. The user would prefer the former since it is much easier. The company would prefer the latter since they can more cleanly separate their software efforts and coordination between groups is kept to a minimum. This is UI separation by business units. I know very few companies who are not guilty of it.
P.S. Do you have an RSS feed from this forum directly into your frontal cortex? I think you replied before I finished the entire post.
02-13-2009 04:50 PM
Very nice work. I guess it will help a lot of developers to understand how specs lead to design.
Some minor points I would change:
* The tuned/not tuned boolean is problematiy for the color blind. I started to use the status boolean of the error clusters as my standard, having checkmark and x.
* I prefer to have the lables to the left of the controls. But it's matching the vertical arrangement of the button navigation.
* Inconsistency of the Ok and Cancel button in the Configuration Dialog. I would use the same arrangement as in the Calibration dialog
Felix
02-13-2009 08:10 PM
Felix,
Very good points.
Though I would say the two dialogs should be consistent and match the example of the Configuration. Having OK on the left and Cancel on the right is much more natural and comparable to other Windows dialogs as opposed to the over and under design that is shown in the Calibration dialog.
02-15-2009 10:07 AM
This is definitely a nice series. I think what might be useful here are some analysis and design documents which could show how you transition from an idea ("a musical instrument tuner") to an actual program and how you would manage such a program (e.g. specs, testing, convetions, etc.).
You might wish to get the moderators to edit your post and add a link to the previous part at the beginning, as well as a link to the nuggets thread at the end. You can do this by clicking the options link at the top right of each post.