Eat Your Dogfood

One of the best things about developing a word processor is that we get to use everyday for our normal work. I am writing our 2005 Marketing Plan right now (lots of graphics and tables, probably 50+ pages once I am finished.) This is my first chance to really use styles for a big-ish document. This is really exciting for me because one of the things that made me want my own word processor in the first place was my frustration with creating structured documents in Word.

Of course, my experience with Nisus Writer is probably like no one else. While I write our marketing plan, I am also testing Nisus under Tiger. When I find a bug, I report it to our engineering team or I fix it myself, which makes for a funny way of working. Tuesday I started writing and then spent most of the day instead making typing more responsive under Tiger. (Its really responsive now.) It paid off though, my writing Wednesday went much faster!

Macworld loves us?

The latest issue of Macworld has a review of Nisus Writer Express. (sorry, not online yet.) We got four mice, which is excellent! (And a great improvement from our last review.) They dinged us for having no bullets and numbering and little right to left support. We are currently working on both of these features for our next release (or two). Maybe next review we can get a 5. (hehe)

EDIT: William Porter, the author of the piece reminded me that they actually dinged us only for lack of numbering, not bullets. We are always hard on ourselves than our critics. ;)

Nisus Writer and Pages

Some people have asked about my reaction to Pages. So here it is: Pages is a simple to use application for creating great looking layouts, but it doesn’t have much in the way of actual writing tools. If you are a serious writer, you need something more focused on writing like Nisus Writer.

In fact, I think Pages and Nisus Writer make great companions: Nisus for writing and Pages for layout. Especially since Nisus Writer documents can be imported by Pages.

Defeasibility

One of the greatest advantages digital content provides is its immediate malleability. With the right software changes can be made quickly and globally. A hallmark of this flexibility is the great big undo/redo stack that nearly every piece of software maintains.

An application normally implements undo by recording inverse operations for every action the user takes. For instance, to undo adding 10 to a particular number, you simply subtract 10. When a user deletes a word from a document, the inverse operation is to simply insert that same word back in.

Looking more closely at the requirements necessary to undo the deletion of a word, you can see that you need to know not only what the word was, but where the word was located in the document. At a lower level this location is simply the number of characters that preceed the deleted word.

For instance, imagine a document containing only the text “ice is blue”. Note that the word “blue” is preceded by a total of 7 characters. So to undo the deletion of the word “blue” from the document, we simply insert the word “blue” after the 7th character in the document.

Locations are complicated by document content that automatically updates itself. One example might be a timestamp. One second the stamp could read “Thursday 23:59”, the next, “Friday 00:00”. You can see that the stamp shrunk by 2 characters. Had our imaginary document in the previous paragraph contained a timestamp such as this one, the location we need to reinsert the word “blue” at to undo the deletion would have changed. To accommodate undo after a timestamp we need to be able to describe locations in the document like “the 7th character after the 2nd timestamp”.