Dr. Newberry openly invited his students to make the program better if they had interest in taking on that kind of project. There were two attempts at creating a prototype GUI for LogicSIm. The first one allowed you to draw circuits, but there was no way to save your work. The second attempt resulted in a clunky un-intuitive interface. Some students would try to use it but most preferred the text-based program.
Eventually a student named Rolly Jones came up with an idea of how to make this work. As a former student in the circuit design course, Rolly was interested in helping future students avoid some of the problems that he had to face.
As a result, a new program called LogicSimGUI or LSGUI was developed for Rolly's senior design project. This program provided an icon based graphical user interface that allowed students to design and build logic circuits that could be visually represented on a screen (within the interface). Students could arrange and connect the various components of a logic circuit; defining the properties of each and how they function together.
Once the circuit design was complete, the program could then be used to automatically create and export a text based file that represented their design. This text file could then be processed by LogicSim to simulate the functionality of the circuit over a given period of time and determine if it performed correctly according the requirements of a given assignment.
Click here to see an example assignment.
The GUI was at least an improvement to the previously used process in which students had to create these text-based files themselves. Rolly Jones wrote a help file to guide first time users through the use of this program.
Click here to see LSGUI helpfile.
He also conducted usability testing to insure that the instructions met the needs of the students who where using the program in this class. He wrote up his findings in an end-of-project report.
The icon-based interface made it easier for students to conceptually design and put together a logic circuit, but the two-step process created the potential for program related mistakes that could easily be overlooked.
LSGUI was also unable to incorporate state machine functionality. In order to simulate state machines, students would have to add the extra text by hand. This turned out to be pretty easy to do. Sometimes it was also easier to just fix the text file in order to make simple changes than to go back and do it within the LSGUI interface. For example, on Linux it could take up to five minutes to save a file.
Teddy Dreiser interview 13:24 (audio link)
The first version of the product, the first iteration of the product, I guess you could call it, the base that we started on was just a user interface, and that did allow users to graphically create the circuit they wanted to simulate, but there was an extra step of exporting the circuit to a text file...adding and modifying the text because the program didn't always output completely correct text. And there was a state machine option that the program did not do anything with, that the user had to go and add manually. And then user had to run and debug their circuit using a text based client that also had limitations as far as loops within a circuit. The output of gate could not go back into an input without going through a register of memory first, because the way the simulation was done.
Get example that demonstrates how LSGUI didn't output the correct text. Emphasize how this is what made it a 2 (maybe even 3) step process.