User:Maury Markowitz/Manifesto for a Better Word Processor

What's this all about?

This page is an experimental effort to collect ideas from anyone who would like to see a better word processor. It started after a short brainstorming session after two of us were talking about FullWrite Professional, which many consider to be one of the best word processors ever written. But along with the good came the bad; it shipped two years late, filled with bugs, and had memory requirements that few machines could meet at the time. The market quickly forgot it, which is ok. But it also forgot all the good ideas it contained. That's annoying.

But what if you could do it all over? Well every so often someone does. For instance Apple just introduced Pages. What I, and hopefully many others, find frustrating are the features they could have simply lifted directly out of other systems and made their own better. The only other "new" word pros of recent history seem to be outright copies of Microsoft Word, in fact many of them boast that's what they are. *sigh* When Word is your goal, you're starting in the basement.

So that's that this page is all about. It's an attempt to collect up good ideas, not so much the particular implementations of those ideas (unless they're good too), but the ideas themselves reduced to their basic concept. So to make sure everyone knows what we should be looking at, let's make a list...

User:Maury Markowitz/Manifesto for a Better Word Processor/What programs do we need to study?

Keep the user in mind!

Certainly one of the biggest problems in the software industry is programmer myopia. This often manifests itself because the developer gets this really great idea to solve one group's problem, and then fails to consider users with similar, but slightly different, problems. Let's not make this mistake again.

For a word processor it seems there are a number of different types of users. Some just want to type, and then worry about cleanup and style later. Others play around with their document, trying out different styles and making lots of little edits. Some need WYSIWYG right from the start because that's how they think. Others don't want to see anything but text right up to the end. There's no reason why a product can't do both. So let's talk about that here...

User:Maury Markowitz/Manifesto for a Better Word Processor/Who are the users and what do they do?

We also need to consider those users who work from an outliner, a seemingly small but important group. This is why people talk about FullWrite even today, it's still mentioned as having the best integrated outliner of any WP ever. For those Word users out there thinking "why would anyone ever use one", just consider the possibility that Word's version is so crappy it's useless.

User:Maury Markowitz/Manifesto for a Better Word Processor/What sort of document views do we need?

Styles and Formats

Here's something to get you thinking: XML/HTML and CSS provide a fairly usable system for styling up documents. With a few additional "non-standard" tags, <SECTION> for instance, the existing HTML standard could be easily adapted for markup of large documents. What's missing is a good layout system (CSS-P is a brain-dead system that cannot work, even in theory) and some easy way to create a single document with a printer and online layout maintained at the same time. So, lets consider:

What you'd end up with is a document that would print exactly as it would from Word (or any other), yet display, without a single change, as a perfectly formatted web page.

Of course this might also cause a problem, because one thing we absolutely need is perfect Word compatibility. MS continues to make noise about going all-XML, but that remains to happen. There's a very big disincentive for them to do this anyway, Office is universal because its document format has become a sort of currency of its own. But the HTML system outlined above would nullify this advantage. Everyone can read HTML, it's even more universal than Word.

undo

Occasionally people open a document, accidentally delete a few lines, and then close the document, and reflexively click "yes" to the "do you want to save changes?" dialog.

What is a good way set things up such that the user can "undo" that unwanted change?

Is it better to

• store the "undo information" in the file itself, like some word processors?
• store the "undo information" in a separate file "next to" the original file in the same directory, perhaps with the same name but a ".~" extension, like the Vim (text editor)?
• store the original version of the file in a file "next to" the original file with a ".bak" or ".orig" extension?
• store the "undo information" for all files in a single centralized location, like most (version control) systems?

pre-emptive saving

Some people open up their word processor and type for an hour before even thinking about what name to give the file when they get around to saving it. Then they get upset when there is a tiny little power glitch and the computer forgets everything. Where should the program pre-emptively store that information, before the user decides on a name for that file?

HOW TO ADD TO THIS DOCUMENT

As this is an experiment, and not part of the wiki proper, it is important that you add new topics with the proper "Namespace". I recommend editing this page and copying one of the links, and then just renaming it.