Last updated 23aug16
The following were the original rationale for creating and assigning this lesson and some are still relevant, while other may be dated and need not be taken too seriously.
The author, David Parker, took a ruthlessly minimalist attitude to his Graphical User Interface (GUI) you see on the screen and interact with on on the keyboard. It does not use a mouse, or pop-up menus, let alone contextual pull-down menus, all of which are now standard. It has only one page of insructions which you need to keep handy somewhere.
Thus, Parker expects you to discover his program's versatility by experimentation and with a minimum of conveniences. You should discover more of its features and record your findings in your Journal. But that is why many (perhaps, most) students are put off by DPGraph. Others, especially the more mathematically inclined, appreciate the challenge of visualizing mathematically defined surfaces with simple, but adequate tools.
And finally, the limitations of this program is a good motivation to more modern and sophicated graphics packages, such in Mathematica. It also makes you glad that there are graphics packages which can be handled with a proper computer language.
And originally, programs had to be composed on a keyboard (well, that was after punch cards) in plain text files using only the symbols you see on the keyboard. Most still benefit from this flexibiilty even though professional programmers genrally use and Integrated Development Package (IDE), some of which can be entirely mouse operated.
So it is fortunate that DPGraph can save your work with its GUI as either a binary file, or a plain text file. The former may be published on the web for example, because it can be viewed by anyone using the DPGraph Viewer which does not require a license. The University has a license. So you can also save your work as a text file, and therefore edit it. You could even compose a new Application (app) by modifying the program of a existing .dpg app in a text editor.
So that is another purpose of this lesson, to motivate the students to learn to use a text editor, or at least how to force the ubiquitous Microsoft Word to edit and save files in plain text, with the suffix .txt. DPGraph is not even obliged to accept Rich Text (.rtf) files.
This skill will be needed in this course.
But it is appropriate to mention here that there are three acceptable ways of writing math in this course, and one unacceptable one. The best is, of course, to make your formulas look like the mathematics in the books and journals. And for this Knuth's typsetting language, TeX, and Lamport's extension, LaTeX, of which you will hear and learn much, but later.
The Second is computer math, which uses ASCII, the lower and upper case letters, numbers, and symbols on your keyboard. This is the language DPGraph insists its formulas must be composed. You'll learn that soon enough after having to debug what you write without much help from the computer.
The third is email math, which is whatever it makes itself understood, but preferably without the symbolic extension of ASCII which are part of Word or .rtf files. Technical people also use words from LaTeX to make themselves clear.
Forbidden is a text which uses the extensed alphabets and symbols common in .rtf, .docx, etc texts. There's nothing intrinsically wrong with using these, exept that therea are still programming languages and applications that cannot digest them, and will probably crash if you insist.
At one place the word "chrome" is used in its origianal sense in computing. It refers to the items around the four edges of a desktop or a window. It no more refers to Google's popular browser than the word "bug" and "debug" refers to the phone abb Weatherbug.
I also used the > notation to describe a sequence of mouse clicks to get from here to there. (Mostly) what comes between consecutive > symbols is what is written on the label of the button, menu, or whatever, you need to select with the mouse. Sometimes, if the label, or even just its unambiguous first couple of words, is still ambiguous, one writes more elaborate descriptions of that step.
This technique avoids the totally infuriating use of unsequential and common English which we all love to hate, such as "do this, but only after you have done that, and before this, which is what you want".