We love feedback! It’s the best way to make the software better.
Bug reporting is the first job of the Beta-Tester. Generally, it is not very difficult to find bugs in Beta release software. More difficult is the process of isolating and reporting the bug in a manner that makes it possible for the programmer to quickly reproduce and fix the bug. Anything you do to help the programmer along will speed the release of MxGUI.
So you run into a bug. What comes next? First you need to be able to reliably and repeatedly reproduce the bug. This is absolutely essential. If the programmer can’t reproduce the bug, he can’t test to see if changes in the program make the bug go away. Second, you need to be able to reproduce the bug in the minimum number of clicks and keystrokes from the time you first enter the program. It turns out that this will help the programmer in two ways. First, the programmer will need to repeatedly make changes in the source code and then run the program to test the changes. The shorter the path to reproducing the bug, the quicker he can see if his changes work. Second, and more importantly, by isolating the bug to its minimum cause, you have managed to tell the programmer where to look in the code for the source of the bug. A clever Beta-Tester can save a programmer hours or sometimes even days of debugging effort tracking down a single bug in tens of thousands of lines of source code.
How does an Beta-Tester find the minimum steps that will reliably recreate a bug? The first part happens _before_ you run into the bug. You need to be careful to remember exactly what you are doing at all times. That way, when you do run into a bug you can think back and recall everything you did for the past 10 or even 20 steps.
Suppose you just found a bug and now you want to be able to recreate the situation in which the bug occurs. The first mistake that novice Alpha-Testers make is that they hurry on, madly clicking this and that, hoping the bug will show itself again. Often, once a bug has manifested itself, the program will begin to exhibit many kinds of strange symptoms: all completely dependent on the first occurrence of the bug. In those cases, most often if you cure the first bug, the remaining symptoms disappear as well. The first thing to do when you encounter a bug is to carefully remember everything that led up to the bug: what panels are open, what preferences were set, and most important of all, what were you doing immediately prior to seeing the bug. It is most likely that the combination of things you were doing is what triggered the bug. The programmer needs to be able to recreate those steps in order to test his cures for the bug. So remember and write down what you were doing, even things that seemed irrelevant to you. “I just went out to the kitchen to get a glass of milk,” might be just a bit too irrelevant.
Next, you need to try to recreate the bug from scratch. By this, we mean that you need to quit the MxGUI, re-start the program and try to get to the bug in the minimum number of steps (clicks of the mouse or keystrokes). This process can be frustrating if you weren’t careful about remembering what you were doing. If you can’t recreate the bug, we will ask you to report it anyway along with your best guess of what you were doing at the time. We will then need to wait until other people run into the bug and we can correlate their reports with yours.
If you can successfully recreate the bug, it’s time to play Sherlock Holmes. Try to eliminate the impossible and whatever remains, however improbable, will be the culprit. Start the MxGUI again and see if you can recreate the bug while eliminating steps. Every time you eliminate a step, you eliminate between 10 and 1000 lines of code that the programmer doesn’t have to consider as a potential cause for the bug. Soon, you will most likely develop a theory for why this bug occurs. We want you to report both the minimum steps to recreate the bug, and your theory for why the bug occurs. A good Beta-Tester can speed up the process of fixing bugs by an order of magnitude.
User Interface Reporting
We need to know about how people perceive the MxGUI software interface. Some things may be surprisingly easy to do and others may be surprisingly difficult. We have been working on MxGUI for so long and we know it so intimately that we can never have the fresh perspective that you have. We need to know what you think about the interface in detail: both the good parts and the bad parts.
It would help us if you kept something of a journal of your experiences with the interface as you first learn to use it. Write down everything that surprises you. If the program does something you don’t expect — something that’s not a bug but just confusing — write it down. If you get yourself into a dead-end where you just can’t get the program to behave the way you wish it would, write it down. Of course, after you’ve learned the program you will know what to expect. That’s why we need you to write it down just as you are first learning to use it. These journals will help us in two ways. First, we can use them to improve our documentation and help files to answer questions from other people who will be confused in the same way as you were. Second, we may be able to change elements of the interface in future releases to eliminate the confusing and unexpected behaviors. The ideal interface works just as people expect and no one needs to refer to the documentation at all.
We would love to received critiques of the interface after you have been using it for some time. Remember, there is a better chance of us meeting your wish-list for features in future releases if you tell us what your wish-list is!
If you want to experiment with other example Mx scripts they can be downloaded from the Mx examples page
Mx Gui Bugs
Known problems with the Mx Gui:
- Some path diagrams from earlier versions may be difficult to modify. This is being worked on.
Please send feedback to the Mx Developer.