Introduction

When it comes to document editing, there are 2 usual approaches:

  1. A WYSIWYG editor such as MS Word or OpenOffice. This is the easier and most known approach.
  2. A document processor such as LaTeX or ConTeXt that translates a document written with a markup language into a human-readable document, often a PDF file. This is a powerful approach that can deliver superior quality.

I was once writing an over 60 pages semester project report with multiple figures and tables in MS Word. As changing some text often caused to misalign the elements that followed in the document, it was such a monkey job to readjust the position of all the elements, only to redo it again after the next text modification. At that time, a friend of mine advised me to use LyX, a document editor that chooses a hybrid approach called WYSIWYM and which uses LaTeX as a backend. It has a user-friendly interface that helps you focus on writing your content, while most of the formatting details will only be visible on the PDF document to be generated. It was a delight for me to be able to write my text in a user-friendly way while not being distracted by formatting details, and to have LaTeX underneath that smartly takes care of all the positioning to generate documents with an excellent quality. However, the documents generated by LaTeX look per default boring, I would say. To remedy that, you cannot avoid writing LaTeX commands, which is not always an easy task:

  • LaTeX is an old and complex document processor that was designed at a time when there was less knowledge as today about good programming practices. So it will take some time for someone to learn to master it. The other possibility is to often copy and paste code from the internet, but then many times run into cases where it doesn’t work as expected for whatever reason.
  • You need to use a bunch of modules to do basic things, and they could conflict with one another.
  • When you make a mistake, you get useless or no error messages, so it’s hard to find out why it doesn’t work.

Some time later, I discovered ModernCV, a LaTeX package that enables to write good-looking CVs. So I spent some time learning the basics about LaTeX and wrote my CV with this package. Over the time, I made some content modification without needing to make fundamental changes, but recently after getting some feedback, I decided to change its structure. As you can guess, it wasn’t an easy task, especially after a long time without digging into LaTeX.

What about a new document editor?

So I had a pretty frustrating experience with the edition of documents that are more than a simple structured document with a few pages. Frustration can be a good thing if you allow it to make you enter a thinking process to discover how things could be better, and then to make change happen. Now I am thinking about designing a new document editor that will be both powerful and easy to use, so that the user can stay productive instead of being distracted with things like alignment issues or by a document processor that makes simple things complex. This is not just a recent whim that I have, as 3 years ago, I already had some thoughts about a better document editor.

What criteria should such a document editor fulfil so that it could be called a success? I can see 3 criteria:

  1. It should be reliable on formatting and positioning. This is decisive for long documents.
  2. It should be also designed for creating documents with a complex structure (like the CV example below).
  3. It is intuitive to use, so that the user can write a document with almost no time needed to search on how to do things.

How to have an intuitive user interface ?

While doing object-oriented programming, I learnt that the closer my modelling is to the real world, the simpler and more powerful will the architecture of my software will be. And while working as a Business Analyst, a.k.a. Requirements Engineer, I learnt that I first need to understand what is the mental representation the user has about the steps he has to accomplish in his task. Only then can we design a user interface that will be both intuitive and powerful.

Let’s take the following dummy CV with some annotations to better explain these ideas:

image

When I see this document, I first see two top level sections: the one on top with personal details (1) and the one below with all the CV entries (2). When I look at the latter section, I see 4 sub-sections (2.n): Professional experience, Education, Knowledge and Interests. They all have the same title style, but the content structure under the title isn’t uniform because the Interests section doesn’t have 2 columns like the other ones. So we can say that in the CV entries section (2), there are 4 sub-sections (2.n), each of them can belong to 2 possible flavours.

Doesn’t it remind you something about object-oriented programming? The point here isn’t about OO programming, but we only do OO programming, because we have observed how real-world entities relate with each other, and we found out that we can do more intuitive programming if we design a software model with virtual entities that relate with each other the same way real entities do. Why not to follow a similar path for document editing to enable more intuitive document creation?

This is how document creation usually works:

  1. The user has a mental representation of how the document to be written has to be structured.
  2. He transforms this representation into a form that can be understood by the software he uses for document creation.
  3. The software produces an output that hopefully closely matches with the mental representation of the user.

In order to accomplish the 2nd point, there can be a lot of time needed to learn the concepts of the software, and/or to find hacks to force the software to produce the desired output. Why not to enable the user to design a document in a way that is much closer to his mental representation? There could be so much time spared!

What comes next?

My plan is first to make a prototype that implements the exposed ideas. Like LyX, it will use one of the TeX based document processor as a backend, so that the user can benefit from its quality and power, while having an intuitive interface that doesn’t unnecessarily expose the complexity under the hood. Once this prototype is done, I will have a better picture of the amount of work the development of such an editor requires. Then I could make a decision whether to proceed further or not.

In my next article, I will show some mockups to give a better picture on how it will look like to write a document with such an editor and explain what are for me the most important considerations for the user interface.