1.

INTRODUCTION

Graphical User Interfaces (GUIs) have been proposed over the years as innovative tools to improve teaching at several levels, from primary school to university, in a plethora of subjects and areas of knowledge¹.

In the particular case of optics and photonics, many approaches have been proposed, such as toolbox-based interfaces², custom designed interfaces³ and web based simulators⁴. Although they have been valid and often inspiring contributions, GUI’s are far from being everyday tools in optics and photonics classrooms. Why? We believe that this is due to four main reasons:

-i) The choice of programming language for the interface: Choosing a programming language is inevitably choosing a set of pros and cons: C++ provides the best computational times but no real plotting and consequent real-time result assessment ability. Visual based languages such as Visual Basic and Visual C++ provide good computational times and real-time assessment, but at an increased complexity that cannot be afforded in the classroom. MATLAB® is the best choice because it is a very popular language in engineering and science courses, it provides real-time assessment with graphical data and there is no requirement of a compiler or a specific operating system³. MATLAB® is a tool that may have been avoided in the past for its low computational yield, but with the improvements in hardware that the Moore’s law has continuously provided, this is a minor issue.

-ii) The lack of open-source: Why are Legos® so popular? One of the undisputable reasons of why Legos are so popular is that these toys can be transformed according to the users needs, tastes and sensibilities. This is exactly the same powerful feature open-source software brings to the table in terms of educational applications. On top of the right choice of programming language, GUI based software absolutely needs to be open-source so that improvements can be made. These can include modifications, small tweaks, and even visual changes. Most of the GUIs presented so far are just showcasing a certain model, which can have flaws and intricacies that may not appeal to every audience. The most flagrant case is the one of the language. If an educator can’t even translate the software to the mother tongue of the students, how can this application be expected to disseminate among the academic world? Open-source freeware developed in a familiar programming environment to the class is an absolute must.

-iii) The application shelf life: Are these GUIs something that the students will be able to use in the future? Can they be valuable tools that they will use further ahead in their professional careers? Extending the shelf life of any kind of knowledge or tool improves its chances of success. Students are keen to invest the majority of their interest in what is foreseeably useful in the future. Open-Source GUIs in MATLAB® have an extended shelf life because they go beyond the mathematical model or physical phenomena that they are showcasing. Mastering GUI programming can be useful for researchers who want to do quick assessments or showcase they’re work in a more engaging way or simply reach a broader audience. Graphical user interfaces are wonderful tools in multidisciplinary workgroups where results need to be presented in the clearest way possible or phenomena needs to be explained without getting into too much technicality. A well-programmed GUI will help the student to learn the classroom material but also it will present itself as something useful and appealing for the future.

-iv) Visual Impact, User experience: GUIs are all about creating a user-friendly, engaging experience. From the moment a user opens a GUI, its design has to appeal immediately and invite for experimentation. First looks are always important, as important as providing a stable, bug free environment, with very quick computation times. Bugs, slowdowns or lack of polish are not welcome in any type of software, and this is especially true for educational software. The programmer has to think as a student. What will be the most likely inputs? What error messages to display when a prohibitive range of values is inserted into the program? Where the results should be displayed and the inputs inserted? What cues should be given and how should they be triggered? These are just some examples of issues that the programmer must consider when developing GUIs, and they are often disregarded.

This paper intends to highlight the critical steps in GUI creation with the GUIDE tool from MATLAB®, but also demonstrate practical examples of it can be used as both a teaching and a research tool.

2.

IMPORTANT ASPECTS OF BUILDING A GUI

There are many tutorials on how to create a GUI on Matlab®. This section of the paper will not focus in the practical aspect of constructing a GUI step by step but rather address the key aspects mentioned earlier with some useful hints and tips.

It is important to first code a single m.file® a base code where all the calculations are made with a fixed set of input variables. The GUI will only add another dimension on top of it, where it is the user that chooses and experiments with different inputs. From the base code, the programmer decides what inputs will be asked to the user and which ones will remain constant. The programmer can also define a range of values that can be inserted. For example, the step size should be a ranged input. Its limits should be ceiled to a number where the computation time is still reasonable and floored to the minimum number where the presented results are consistent.

To sum up, it is recommended that the GUI creation is a two-step process: first a single m.file with the “core” code is created and tested, to assure that the model works perfectly. The GUI is programmed on top of the base code, where all the visual elements are added. This assures that at leas two distinct debugging sessions are made, one for the code and the “mechanics” of the model itself and other for the visual elements of the application.

Figure 1 shows the main window of the GUIDE tool. On the left the user has a set of interface elements to drag and drop to the drawing area on the right. Data can be presented in three different forms: in text boxes, plots or tables. We strongly recommend plots over tables. Text boxes should no be used to present results but rather the values off constants or single parameters that are not to be editable.

Figure 1:

The GUIDE main window.

Figure 2:

Two panels in an example basic layout.

Panels are very important design elements that are often ignored or put aside. They improve the aspect of the GUI and have the important task of grouping large number of interface elements: it is easier for the programmer to move or resize the entire panel instead of doing it for every single button, and it is easier on the eye of the user to have categorized sets of buttons. An example of an already built interface is shown in the next figure.

Figure 3:

A steady-state erbium-doped fiber analyzer.

Having a single window with categorized button panels provides ease of interaction and a large area dedicated to plotting is crucial for quick assessments. If the results often require larger plot areas a button to pop up the graphical area onto a separate window should be made available.

Alternative forms of input such as sliders are welcome, because the user can only use his mouse to control all the GUI, bringing not only commodity, but also making it easier to use for incapacitated students.

Figure 4:

Sliders placed beneath the text input boxes.

Having a single window with categorized button panels provides ease of interaction and a large area dedicated to plotting is crucial for quick assessments. If the results often require larger plot areas a button to pop up the graphical area onto a separate window should be made available. Plot options should be organized in a pop-up menu so they are concealed yet promptly available on the menu is activated.

Figure 5:

On the menu, pop-up button and “hold on” button, on the right the several plot types that can be chosen when the menu is selected.

Having a single window with categorized button panels provides ease of interaction and a large area dedicated to plotting is crucial for quick assessments. If the results often require larger plot areas a button to pop up the graphical area onto a separate window should be made available. Plot options should be organized in a pop-up menu so they are concealed yet promptly available on the menu is activated.

3.

EXAMPLES OF GUIS

The first example of GUI is a steady-state EDFA analyzer, presented above in Figure 3. It was developed to be both a research and an educational tool. The aim of this particular work was to create a simulation platform using MATLAB®, a tool that is both available to educators and researchers: an accessible tool, easy to use, that allows users to change all the desired parameters and functions in a quick fashion. Steady-State models are useful when wants to study the influence of each individual parameter in the overall performance of the amplifier. In order to do so a GUI has to provide quick computation times and a good visualization so the impact brought by parameter variations can be immediately assessed. As it can be seen in figure 3, this GUI consists in a single control window. All the important parameters (every non-fundamental constant) are editable and shown in the panels right to the graphical area where the results will be plotted. There is a number of plot options from which the user can choose. There is also the option to hold on the current plot so different results can be compared in the same window, or, as mentioned before, the current graphic can be shown in a new window outside the GUI by ticking the “pop-up” box. If neither the “pop-up” nor “hold on” boxes have a tick, the GUI will simply replace the old plot with a new one as soon as the update button is pressed. There is also an important pop-up menu with all the important options.

It is almost excused to mention that the GUI is completely open-source, every exampled showcase in this paper is. New users can add their code lines to the already existing ones, creating more plot options for the rollover menu, or simply change the visual aspect of the GUI with simple drag and drop operations with the mouse.

This GUI was originally presented at EUROCON 2011- International Conference on Computer as a Tool as a research and education tool⁵. It is a valuable GUI not only to be presented in a classroom to illustrate the basic principles of operation of an Erbium Doped Fiber Amplifier (EDFA) but also a handy tool for the laboratory, where quick calculations can be made before or during experiments. This GUI also proved to be useful to explain concepts and discuss results in a multidisciplinary team with physicists and electronic engineers, where the latter were no familiar with the physical concepts behind an EDFA.

In steady-steady models the input power is assumed to be constant, making them fast computational models ideal to be presented on a GUI. Although time dependence is a very important aspect of modeling EDFAs, it is not necessary if the user wants to assess and study the influence of the physical parameters of the amplifier, making the GUI a very suitable application for that same purpose.

But since there was an interest and a need for a time-dependent model, a GUI was created in order to do so. This presented a challenge, because the main interest of creating a dynamic model is to study add/drop scenarios. The algorithm as to adaptive in order to solve the necessary number of equations which varies accordingly with the number of add or drop operations and the GUI as somehow to allow it without losing its key features. Ideally, the user would have two separate windows in the GUI, one for defining the add/drop operations and other for visualizing the results but that means complex programming in the second stage of the application development, which is highly undesirable and against the principles of a good interface. GUIs have to be maintained has simple as possible, not only for the sake of an user-friendly interface but also for the aspect of computation time. The computation time should be associated to the core of the code and not to the graphical element and kept as low as possible. Despite all these constraints, compromises can be made and a valuable tool for education can still be produced, one that would illustrate with rigor the concept of adding or dropping a channel and its associated phenomena. In order to do so, the maximum number of add/drop operations in the GUI was limited to 4 while the number of channels limited to 8. The core algorithm that the interface is running is more than capable of calculating a limitless number of add/drop operations, but turning it in a successful GUI is a difficult task. That is not a limiting factor if proper limitations are performed.

The developed GUI can be seen in figure 6 below. When the GUI is started, all the necessary input boxes and pop-up menus for 8 channels and 4 operations are displayed. But, as soon as the user chooses an inferior number of operations and channels these boxes disappear, only to show up again if corresponding number of operations or channels is inputted again. These dynamic features are very easy to program with IF cycles that scan the properties of every visual element (button, box, pop-up menu) and are of great visual aid to the user.

Figure 6:

Dynamic EDFA GUI.

As for the rest of the GUI, it follows the guidelines of its antecessor: A good graphical area, with the possibility to popup and hold on. It is also useful to remind that this GUI is running on MATLAB®, and that means that every usual plot tool (zoom, legends, save) is available from the start.

The last GUI example (figure 7) is a recently developed GUI for studding closed form expressions of an analytical model for nonlinear propagation in uncompensated long haul transmission links⁶.

Figure 7:

GUI for parameter optimization of a model for non-linear phenomena in uncompensated long-haul transmission.

The idea once again was to study the model for a very large number of scenarios, modulation formats and parameter values. The ideal tool for a researcher to showcase results and fine-tune every parameter individually is a GUI. Since this model is able to predict quiet accurately the reach in transmission links, a very handy tool even for commercial purposes was developed.

4.

CONCLUSION

The main factors for successful GUI were addressed, and important tips and hints for building a GUI using the GUIDE tool in MATLAB® were addressed. A GUI needs to be visually appealing and easy to use, open source and have a broad range of applicability, rather than just being focused in education. Examples of GUIs were demonstrated, as well as possible challenges and the means to overcome them. The programmer must learn to develop always with the users in mind and compromise and adapt when necessary. The example GUIS were always developed in a research context but its adaptation to the classroom is very easy and straightforward. Depending on the model or subject in question, GUIs may even have commercial value.