Lately, I have been working on getting my few office suite needs moved over to something a little more text based. I find GUI apps pretty inefficient for these kinds of tasks. Understand that this is not an open source vs. closed source discussion. OpenOffice.org Writer and Microsoft Word get grouped together, as one is basically an open source cross platform version of the other. This is actually contrasting two different application philosophies. I am, in fact, looking for something that is more usable.
Usability is a commonly trotted out concern when evaluating software. Now, when the word is thrown out, it is loaded with a specific meaning that is actually improper to its use. Usability is conflated with something that has a flat learning curve. So flat, that it is assumed that the hypothetical user could learn the application every time they start it. It is assumed that it usability refers to the flat learning curve as opposed to a tool that requires a little more upfront effort. This is unfortunate, because usability is actually a slider between the two extremes of "easy to learn" and "efficient to use". Where a "usable" application falls on this continuum is up to the user in question. Commercial software naturally gravitates towards the "easy to learn" end of the spectrum, because it is the end that accommodates the greatest slice of the populace. Even the more hardcore of us can get by with software that still has the training wheels on.
So, the usability I am looking for is one of efficiency not of expediency. I want apps that will allow me to produce what I want fast and roll on. I am willing to accept a steeper learning curve upfront, it it means time savings later on. This is, for example, why I am using Vim for day to day text editing (like programming) rather than jEdit or syn. Sure, it took longer to learn upfront, but I can move through a text file fast.
Some other considerations for me was that I like using tools that I can use from a straight terminal because it means that I can access them over SSH. No need to sync files, just remote in to the machine carrying the files. This may not be a concern for most users out there, but it makes my life a lot more convenient.
As an example, this little spiel started with the search for an application I could use to draw process flows in a declarative manner. It does not take much to be able to pull open Visio or Dia and draw the diagram. When you think about it, that drawing process takes longer than seems necessary. You click the tools in the pallets. You click through the properties. You drag. You drop. You do a lot of work to draw a picture. However, if you can simply declare the relationship, it would be a lot more efficient. That is what I was looking for, but what I’ve set up is a nice little replacement, for everyday use, for OpenOffice.org/Microsoft Office. So, here goes my list.
Graph/chart drawing & diagramming
Graphviz. More typically used for diagrams produced in mathematical articles (writing on graph coloring algorithms, for instance), this little tool will produce directed or non-directed graphs. The syntax is simple and C-like, allowing one to declare nodes, with optional properties, and edges connecting them.
The biggest two CLI email clients are mutt and pine. Mutt is clearly the more configurable of the two, but Alpine (the new, completely OSS version of Pine) is quick and easy. My biggest annoyance with Alpine is its heavy verbosity. There are plenty of "are you sure?" prompts. Ultimately, I found Sup. Sup is self-described as being a sort of text-based version of Gmail. Sup wins hands down with a nice interface and a powerful search engine.
Word processors have gotten huge. Nonetheless, most of what they have to offer is seldom used. The Word power users I have heard mention this always do so with a touch of regret. As though we all should spend more time learning to use Word. The fact is, most of those features go unused because people don’t need them. I fit firmly in that category. I wanted a markup system I could use so that my documents would be composed in pure text (allowing me my precious Vim), but easily run through into something more print ready or presentation ready.
I considered TeX or LaTeX briefly. However, two things about them bothered me. First, there was the sheer ugliness of the markup. The large quantity of line noise interjected into my manuscript as I was composing was simply too much. It distracted too much and was too cluttering. Secondly, there was the heavy mathematical and scientific bias. A good portion of the documents I work on are related to my fiction writing. The ability to pretty print mathematical formulae is not helpful. So, the trade off was simply not worth the benefits.
Wiki syntax is a good example of what I wanted. Plain, non-cluttering, and very close to an ASCII version of all formatting. A little bit of research brought me to Markdown, Pandoc (which accepts Markdown), and AsciiDoc. My favorite of these is AsciiDoc. Its native backends are HTML and DocBook. However, DocBook (around which AsciiDoc provides a wrapper utility) can be converted to many formats, including PDF, ODF, and RTF. So, if you use this, you can create something that just about anyone can open. Pandoc actually offers more native backends than AsciiDoc (including DocBook, so the same ups apply), but generates plainer HTML. Sure, I can style it. I can make it default by aliasing pandoc to pandoc -c mystyle.css. Someday, I may even do it, but right now I am lazy. I don’t want to have to write a reasonable CSS file for quick and dirty use. So, I am using AsciiDoc for now because it caters to my sheer laziness.
Most uses of spreadsheets are evil. It seems that a lot of the world tries to use Excel like a database system—which it isn’t. However, their utility for quick little things cannot be ignored. Besides, I still have to deal with the spreadsheets I receive. I found two modern day, command line driven spreadsheet systems: sc and Oleo. sc is older, its source having its origin as a public domain application on USENET. Its interface is largely inspired by vi and less. Oleo is GNU’s spreadsheet application and so, understandably, takes its cues from Emacs. The most important command, C-x C-c, is the same. Naturally, when you put it that way, I have no choice but to fall in with sc. It is a nice little piece of work, allowing quick manipulation of data. Neither of these applications will generate pretty pictures for use in a word processor, but we quickly find ourselves rescued by the UNIX philosophy of a tool for every job. sc/Oleo do not need to provide ways to dump out pretty pictures—that is not their job. They crunch data. We use something else to create graphs.
Those TODOs that we all have to keep. Microsofties keep them in Outlook. Anti-computerites either keep them on paper or not at all. The best text-based system I have seen is TaskWarrior. It is truly awesome.
Another application that is integrated with Outlook and Exchange for most users. The command line applications are, of course, more loosely coupled. The best event scheduling calendar I found was Pal. Pal looked like it was more heavily geared towards the way people think of calendering.
IM is not a part of the traditional office suite, but, it is becoming a regular part of most offices. Finch is the clear winner on this front. There are plenty of text based IRC tools, but Finch is built on top of libpurple and supports all of the protocols that Pidgin does.
Again, I suppose this is not really a part of the traditional office suite, but we all want one. There is a reason Windows ships with Media Player. It is because Microsoft recognized that people wanted one and if it didn’t ship with Windows people would (horror of horrors!) use non-Microsoft software. My favorite GUI music player is Amarok. On the CLI side, Moc and CMus are excellent choices. MOC seems a little more intuitive.
Unfortunately, the formats version of musical chairs does not usually permit us to keep everything strictly text and HTML. Those of us who are still part of the real world have to accept and send files in popular formats. Fortunately, OpenOffice.org allows exchanges between the backends of many of the formats that would be required. Unoconv, a Python script to interface with the headless version of OpenOffice, makes those conversions easy from the command line.
I am sure that there are people for whom this type of setup would be simply unworkable. Computing ability aside, it emphasises work on content, not work on layout. Obviously, if you are making flyers every day, AsciiDoc is not for you. You could insert images (generating your word art through some ImageMagick kung-fu) and generate a PS file that you lpr off to your printer, but it would probably not be an optimal workflow. However, I do work on content. My programs are content. My stories are content. I am a content person, not a design person, so, for me, this is an excellent layout.