A Lasting Theorem

Here is one of the world’s most difficult mathematical problems:

For the equation: an + bn = cn, where a, b and c are whole numbers, n must equal 2. In other words, this equation only works if n =2.

For example, the following numbers fit this equation:
32 + 42 = 52 and 52 + 122 = 132. If n equals 3 or any other number, you won’t find any solutions to this equation.

This problem is known as Fermat’s Last Theorem, named after the French mathematician Pierre de Fermat, who lived during the 1600s. While annotating a book about mathematics, Fermat claimed to have found a solution. He wrote: “I have discovered a truly marvelous proof of this, which this margin is too narrow to contain.” Too bad he wasn’t using a Word processor with its ability to add notes of unlimited size.

The problem remained unsolved for over 350 years until a British mathematician named Andrew Wiles finally conquered it in a monumental 200 page proof. How he solved it is a fascinating adventure into the strange and mysterious world of higher mathematics.

Wiles’ solution involved two very strange mathematical shapes: elliptic curves and modular forms. Elliptic curves resemble doughnuts, whereas modular forms don’t resemble anything and are therefore much more difficult to describe, but here goes:

A modular form is an incredibly complex, highly symmetrical form with many dimensions. It is impossible to draw one because it only exists as a conceptual form.

Elliptic curves and modular forms are very different from each other. However, the solution to the theorem involved proving that these two shapes, are, in fact, the same. When the idea that these two forms might be identical was initially proposed, it was a radical concept. It was like saying that an elephant is a banana, which is, quite simply, bananas.

However in 1995, Wiles proved these two forms were indeed identical. In doing so, he solved Fermat’s Last Theorem. How proving that these two forms were the same also solves Fermat’s Last Theorem is beyond the scope of this article. (For a full explanation, read the PBS transcript from the Nova documentary, The Proof.)

Mathematics and technical communication both attempt to model reality, and both use informational objects to do so. The primary object (or shape) that a technical communicator develops is the information repository, which is comprised of:

    1. Topics (such as overviews or procedures) that answer specific questions.
    2. Containers and sub-containers for the various topics (such as other topics, pages, chapters or other sections).
    3. A function enabling the user to search the topics (an index, TOC, or content search function).
    4. An environment that contains all the topics and the search function (for example, a PDF, help system, or website).

     Users deal with another shape: informational queries, which are comprised of:

      1. The generation of specific questions, such as “what is this thing?”, “how do I perform this task?”, “how do I resolve this problem or error?”
      2. The process of determining where to find the answers.
      3. Locating the relevant information repository.
      4. Searching the information repository.
      5. Locating the topic that they hope will answer their question.
      6. Understanding the answer to their question, that is, the contents of the relevant topic.
      7. Successfully resolving their question, for example, by understanding a concept, completing a task or resolving a problem or error.

      Both of these shapes require all of their respective components in order to be considered complete shapes. For example, an informational query is incomplete if the user can only complete the first six steps. They may find and understand the relevant help topic, but if they cannot complete it (due to an error in the topic, the product or both), then the informational query is incomplete.

      Just as elliptic curves and modular forms, two radically different shapes, were proven to be the same, both information repositories and informational queries are the same. This is because each shape is a reverse-engineered version of the other.

      When a technical communicator creates an information repository, they are attempting to recreate the steps that a user will follow in an informational query.  Communicators try to anticipate as many of the questions that a user will have, then work backwords to create a resposity that will the answer the user’s question.

      We can take the steps of an informational query, change their order (mostly by reversing them), and then structure them from the perspective of the technical communicator:

      1. Consider all the potential questions a user could have.
      2. Create topics that successfully resolve these questions.
      3. Ensure the topics are written so that the user will understand them.
      4. Index the topics so that they are searchable.
      5. Create a search system that will enable the user to find the relevant topic.
      6. Place the information repository in a location where the user can access it.
      7. Make it obvious to the user where the information repository is located.

      Conversely, we can reverse engineer an information repository from the user’s perspective:

      A user needs to:

      1. Locate the environment containing the relevant document that will answer their question.
      2. Search the topics for the answer.
      3. View the various topics that might contain the answer.
      4. Find the topic that answers the question.

      One shape is but a mirror-image of the other.

      The commonality goes even further, for all end users are potential communicators, and all communicators should ideally “be” the end user. The greatest documentation is created when end users actually communicate directly with the technical communicator, and when the technical communicator imagines themselves to be the end user, with all of their worries, concerns and, most of all, questions.

      In fact, I have developed a formula that proves the number of end users in the world is equal to the number of technical communicators.

      Unfortunately, this blog is too small too contain it.