MBX Tip #1. Use cheat sheets This is the first of an irregular series of (hopefully) helpful advice about using MathBook XML. Looking back at the April workshop at AIM, it struck me that the most difficult activity for many people was learning to use git. If I had to lead that session again, there are two things I would have done differently. The first is to make sure everyone was really using the git cheat sheet. Appendix D of the "Git for authors" document is a cheat sheet for the typical steps you use to contribute to a large project on GitHub. As I replay that day in my mind, I do not recall seeing most people using the cheat sheet. As an experienced programmer, I understand the value of a cheat sheet, and I used my own hand-written GitHub cheat sheet for at least a year. It wasn't until I started helping other people to use git that I stopped needing it -- and that was only because I had memorized it from repetition. Note that I said "memorize," not "understand." I still don't feel that I really understand git, and if I encounter a situation outside the usual development cycle then I need to look things up or ask an expert. But I don't need to understand git: I just need to repeatedly do the same routine steps. So, use a cheat sheet. Start with the version in Git For Authors, and then annotate it for your own use. For example, if using the terminal (command line prompt) is new to you, then you may need to add some additional notes about using the command line. What is the other thing I would do differently? That will be the topic of my next MBX Tip. =============== MBX Tip #2. Arrange your windows like a pro Most of you work on a large computer screen. Even most laptops have enough room that you can have two windows open at once. As I am typing this in one terminal window, next to it I can part of a web browser, and just below this terminal window I can see the bottom few lines of another terminal window. You could have a similar arrangements of windows when you are writing a document in MBX. If you are in the habit of "maximizing" the window you are working in -- making it fill the screen, then you are adding a huge amount of overhead to your work. Every time you have to switch tasks it adds a few seconds and some extra mouse clicks. Those add up to a lot of wasted time and mental fatigue. Consider the cycle: 1) Modify MBX file 2) Re-run xsltproc 3) Look at new HTML version of document (recall the advice to use the HTML version instead of the PDF version for development!) 4) Go back to 1) If you have the windows arranged as I described above, then going from 1) to 2) just involves clicking your mouse on a large target, hitting "up arrow" and "return". Going from 2) to 3) just involves clicking on a large target, and then clicking "reload". And doing 4) is just one click on a large target. Those steps are much faster than anything that involves pulling down a menu or typing a command. You should also figure out how to have multiple "desktops" on you computer. That way you can have your windows set up for MBX development, and those can stay set up always. Those windows don't add clutter when you are doing other work, and your MBX desktop is clean and just has the minimum needed for writing your book. =============== MBX Tip #3. Theorems often have introductions or conclusions Consider these fictional extracts from math textbooks: Example 1 ------------ The following is a generalization of Theorem~\ref{thm:abcd}. \begin{theorem} If $a$ is even and $b$ is odd then $a+b$ is odd. \end{theorem} Example 2 ------------- \begin{definition} We say that $f$ is \emph{continuous at} $a$ if $\lim_{x\to a} f(x) = f(a)$. \end{definition} Note that the limit in the definition is equivalent to three things: \begin{enumerate} \item $\lim_{x\to a} f(x)$ exists, \item $f(a)$ exists, and \item those two values are equal. \end{enumerate} Also recall also that the existence of $\lim_{x\to a} f(x)$ means that the limits from both the left and the right exist, and those two limits are equal. ------------------ What the examples have in common is material that is closely associated to the theorem/definition, even though it is not part of the statement of the theorem/definition. That situation is captured by the "introduction" or the "conclusion" in MBX. The first example could be translated to MBX as -------

The following is a generalization of Theorem.

If $a$ is even and $b$ is odd then $a+b$ is odd.

------ The second example would have a statement and a conclusion (and \emph{continuous at} would become continuous at). How do you know if you should put some material in the introduction or the conclusion? 1) If you were going to move that theorem/definition to another location in your book, would you also need to move the paragraph before or after that theorem/definition? 2) If someone were going to assemble a new document from pieces of several other documents, would they find it helpful to include those other paragraphs? 3) When in doubt, put material in an introduction or conclusion, instead of having it in disembodied paragraphs that just happen to appear before or after the theorem/definition. The visual appearance in the current LaTeX or HTML version will probably be the same, but you are adding valuable semantic information to the document, and that will be useful in the future.