To Undo or not to Undo..

[ecbrown]

First of all, my post was meant more as a compliment to RedleX for providing an excellent, stable working environment. I think that everyone is pleased with this aspect of Mellel.

I lived in an apartment for a year where the power went out unexpectedly at least once a month. I had a desktop computer. Lost many a research paper that way.

I more recently (while writing final papers last semester) lived with a new laptop with bad pre-installed memory for about a month before I was able to leave it at the Apple Store for them to diagnose and correct the problem. I had six kernel panics in one two-day period, but didn't lose any work thanks to reflexive cmd-S-ing every time I paused to think.

These are unfortunate circumstances. Ones does have Autosave in case one needs it. If you use undo a lot, change the Autosave frequency.

I don't think it is useful to ask where the obsessive saving mentality comes from.

This is a Discussion forum, and the subject is "Undo or not to Undo..." In order to answer this question, we should flesh out the advantages and disadvantages of having essentially infinite Undo. You know the Redlers can do it, but they made a decision to clear upon Save. I suspect that it is because keeping an Undo buffer eats up resources. These resources are hard-pressed on my 700 MHz EMac with 512 of RAM.

The job of a software developer is not to question or correct the psychology of his users, but to understand and work with that psychology. If a reflex or expectation exists, it probably exists for a reason. So the more useful question is what relationship users expect to exist between undo buffers and saving, in order to try not to subvert it. I think most users would agree that there is no implicit or intuitive connection between the two things, if only because that expectation is conditioned by every single other popular word-processing program on the market. Whether it makes logical sense or not, Mellel subverts common, conditioned user expectation, and that constitutes a misbehavior, even if it's called a feature.

I fully expected Mellel to suck just like all the competition. But I was wrong. It is a different model for word processing. One actually expects to do ad hoc formatting of the text. Nope, Mellel uses styles. It is better, in my opinion. Despite twenty some years of doing ad hoc markup, I have to change my way of doing things. I should define a style set before I go typing on my document.

What's the point? Mellel lets me do more with less. I can run it on my clunky old machine while working with files over a slow network connection (.Mac) without copying to the local machine. I used to hit Apple-S every ten seconds and wait while it dragged the large files and their graphics over the network. That got old really fast, until I realized... "why in the hell am I saving so often? Open the document, work on it, and save it when I am done working on it!"

Eric

p.s. no, please don't let undo be infinitely persistent--I don't want someone to get my document and be able to undo it. They might see something that they should not see. Also, the manual should say that Undo is flushed upon save. This would avoid any surprises for new users.

[zoul]

please don't let undo be infinitely persistent--I don't want someone to get my document and be able to undo it. They might see something that they should not see.

Nobody wants that – this is about being able to undo all changes made since opening the document. I do not think this would be a major resource hog, since infinite undo was already available years ago when machines only had a few tens megabytes of RAM. Even if it is a major resource hog, I have a gigabyte of RAM to spend on such luxury and want it, so that it should be at least an option that could be turned on in the preferences. Describing the current behaviour in the manual is not a solution – the poll clearly shows that most Mellel users want infinite undo. I run into this issue about twice or three times a day and even though it is not a major source of pain for me, infinite undo would certainly make my life easier. (And editing texts, too :-)

[kjmatthews]

I don't think it is useful to ask where the obsessive saving mentality comes from.

This is a Discussion forum, and the subject is "Undo or not to Undo..."

Well-taken. I didn't mean for that to be quite so strongly worded.

I fully expected Mellel to suck just like all the competition. But I was wrong. It is a different model for word processing. One actually expects to do ad hoc formatting of the text. Nope, Mellel uses styles. It is better, in my opinion.

Still, I think there is a fundamental difference between what you're talking about and the undo/redo model. The fact of the matter is that you *can* make text block X double-spaced if you want to - you can even do it ad hoc, if you are intrepid and don't mind Mellel inventing temporary styles. Styles are a different means to achieving the same ends. The problem I have with resetting the undo buffer is that one no longer has ANY means of recovering that data—not a different, new way, but none whatsoever.

I am not in favor of an infinitely persistent undo either. The undo buffer should be reset when the document is closed, at the very least (rather than when it is saved). 20-50 (at most 100) last actions would be plenty for me.

[ecbrown]

Describing the current behaviour in the manual is not a solution – the poll clearly shows that most Mellel users want infinite undo.

As to the manual, I did not mean that it is "a solution" but rather a "must" if this is the way that Mellel currently behaves. Also, let me underscore that I don't mean to poo-poo other people's requests for features.

I could be completely wrong here. But I would like to discern whether unlimited undo is mostly a luxury item which contributes to bloat and forced hardware upgrades. This is a serious issue for people who oversee underfunded school/academic labs. It is also a big problem in places which are lucky enough to have an old donated computer. And my mother (pauses, smiles fondly) would freak out if she had to buy a new computer.

These features may come with a significant cost. Undo-from-the-point-of-open is something that could, in principle, turn Mellel from being "an agile, feature-rich, reliable word processor" into the dog that is Microsoft Word, especially for book-sized documents with lots of figures. This feature could drastically affect the "state" of Mellel. That undo information has to go somewhere, and it will eventually force a disk/network write which will slow things down.

When is a good time to clear the Undo Buffer? How about when you save to disk? This is the current behavior, and I think that it takes advantage of the psychology of users and their tendency to save frequently. Therefore, I suggest to those who must have "unlimited undo" do two things: 1) increase the time between autosaves 2) stop hitting Apple-S all the time.

This will satisfy the people whose workflow would be interrupted if the feature were to be implemented. I'm only indifferent to the feature. Imagine what is going through their heads I hope that I am not coming off as obstinate, but rather trying to deduce why Mellel is the way that it is currently.

Eric

p.s. kjmatthews, i think we're on the same page now

[zoul]

I could be completely wrong here. But I would like to discern whether unlimited undo is mostly a luxury item which contributes to bloat and forced hardware upgrades. This is a serious issue for people who oversee underfunded school/academic labs. It is also a big problem in places which are lucky enough to have an old donated computer. And my mother (pauses, smiles fondly) would freak out if she had to buy a new computer.

:-) I could be completely wrong, too, but I think that unlimited undo in word processors does not cost much system resources. The text is after all just a text and even a single megabyte of memory should be enough to store quite a long document. The undo buffer does not contain the whole document for every “revision” – with sane implementations it only holds the differences to the previous document version (*), so that it is very easy on memory.

(*) And these can even be only references to text blocks, so that they cost virtually nothing. I once read about the undo implementation in Word and now I actually managed to dug up the document, it is about a bug in Word for Mac and I found it to be quite an interesting reading.

These features may come with a significant cost. Undo-from-the-point-of-open is something that could, in principle, turn Mellel from being "an agile, feature-rich, reliable word processor" into the dog that is Microsoft Word, especially for book-sized documents with lots of figures. This feature could drastically affect the "state" of Mellel. That undo information has to go somewhere, and it will eventually force a disk/network write which will slow things down.

I am a programmer, but I do not know much about these things. Let’s hear what the developers think about this – I think that even large documents are pretty small in memory (judging by modern standards) and that the undo buffer would be pretty small, too. There are quite a few applications that support unlimited undo (Vim comes to mind) and I do not think they have performance problems because of it. (And be sure that Vim can edit very large files.) I also googled up this page that says: “In just about all applications the undo history is lost the moment you close the document. There is really no reason for this since the undo history (if it is properly implemented) hardly takes up any space, and there is no guarantee that you won’t need it at a later time.”

So, to sum things up: Properly written undo/redo should not make Mellel noticeably slower and if it by any chance will, it can always be accompanied by a preferences option that will turn it off for people who want or need to. I’d like to hear what developers think about this.

[aechallu]

I'd rather have Mellel act as it does now, but implement a versioning mechanism -- which could be as simple as just setting back the clock to a previous [saved] version. I hope Time Machine would allow the developers to implement such feature with relative ease.

If versioning is out of the question, then (optional?) persistent undo would be a consolation price.

[hlb]

I think—and this has been mentioned in several posts here—that the controversy surrounding this issue could easily be resolved by making unlimited undos a feature that the user can turn on or off in the preferences, rather than forcing one mode (which many of us clearly find undesirable) on all users. Text takes up ridiculously small amounts of memory space and on most modern machines, unlimited undos would pose no performance problems. I fully understand that there are those who do not have access to more up-to-date computers—again, simply give them the ability to disable this feature.

I for one find this behavior of the application irritating to such a degree that I'm seriously considering ditching Mellel at this point. Continuously hearing that "blong" sound after hitting CMD-z instead of seeing my text revert to its prior state is starting to grate on me. I've waited quite a while and they're obviously unwilling to fix it. But this example of "thinking different" is about as 'useful' a design decision as Apple's "Mighty Mouse."

[Mart°n]

Very interesting topic on which I like to post some thoughts. As I don’t like to write 5 single answers, I’ll answer the posts of several people here:

What is the origin of the "hit apple-s" every ten seconds mentality?

I lived in an apartment for a year where the power went out unexpectedly at least once a month. I had a desktop computer. Lost many a research paper that way.

One important thing to keep in mind during this discussion. People don’t like to “save” a document that often but they like to ensure that not a single character will be lost no matter what happens to the computer.

So the more useful question is what relationship users expect to exist between undo buffers and saving, in order to try not to subvert it. I think most users would agree that there is no implicit or intuitive connection between the two things…

I agree. A user can’t see or guess what happens to the undo buffer if he saves or prints a document. Both features are provided by Mellel and they should work independent from each other.

I more recently (while writing final papers last semester) lived with a new laptop with bad pre-installed memory for about a month before I was able to leave it at the Apple Store for them to diagnose and correct the problem. I had six kernel panics in one two-day period, but didn't lose any work thanks to reflexive cmd-S-ing every time I paused to think.

These are unfortunate circumstances. Ones does have Autosave in case one needs it. If you use undo a lot, change the Autosave frequency.

This isn’t a helpful suggestion. One uses auto-saves to ensure that no part of the document will be lost. If I change the frequency but have to live with circumstances that could cause my computer to crash or to power off, I have to save a document more often. Even with a reduced auto-save rate, the exact time when the document will be saved is not transparent to the user. If you work on a paragraph, read it again, decide to delete it and the auto-save jumps in, you don’t have a chance to undo the deletion. That’s a bad behavior, no matter how low you set the auto-save frequency.

This is a Discussion forum, and the subject is "Undo or not to Undo..." In order to answer this question, we should flesh out the advantages and disadvantages of having essentially infinite Undo. You know the Redlers can do it, but they made a decision to clear upon Save. I suspect that it is because keeping an Undo buffer eats up resources. These resources are hard-pressed on my 700 MHz EMac with 512 of RAM.

These resources really aren’t hard-pressed on a eMac with 512 MB of RAM. One example. A very good writer could write about 500 keystrokes per minute. If you or a team of people match to write those 500 keystrokes every single hour, 24 hours a day, the result will be 720.000 written characters (taken as the most optimistic – or worst case). This equals 154 A4 pages with 12pt, single line spaced Times New Roman. That amount of characters equals 703 KB of RAM, saved in a uncompressed Mellel document, it’ll use 830 KB of hard disk space, saved in compressed Mellel format, it’ll be 12 KB on your HD. So even if you match to write that much a day, it will not even scratch your 512 MB of RAM. If you write 24 hours a day with a constantly speed of 500 characters per minute, you’ll have to write nearly two years (every single day, every single minute) to fill up your RAM with written text. If you write only 8 hours a day, you’ll need about 6 years for this. Nothing else will then fit into your RAM but the example above only should visualize how hard it is to fill you RAM with written text. So a unlimited undo doesn’t hurt your Mac. Every Mac that could run OS X 10.2 (the lowest requirement to run Mellel) easily could manage a unlimited undo. Nobody will have to buy a new machine because of this.

What's the point? Mellel lets me do more with less. I can run it on my clunky old machine while working with files over a slow network connection (.Mac) without copying to the local machine.

The second Mellel opens your document, you have copied it over to your local machine as Mellel reads the whole document before you could work on it. So you’ll only notice the slow connection the first time you open a document and every time you save it. As backup copies are saved on your local machine (if set in the preferences), the undo history could be saved there too. This way a slow network connection couldn’t slow down the felt speed of Mellel.

p.s. no, please don't let undo be infinitely persistent--I don't want someone to get my document and be able to undo it. They might see something that they should not see.

There are different possibilities of implementing a infinite undo. Storing the information inside the Mellel document is one of them, saving the information to a undo history file on your hard disk is another. I would prefer the latter so that there’s nothing inside your document that shouldn’t be there. This means that the unlimited undo will not be available if you move to another machine, but that may be something that one could live with (or that could be solved by a mobile Mellel package, that stores your Library/Application Support/Mellel and Library/Application Support/Fonts folders and your Mellel preference file on a USB Stick so that you could run Mellel with all the set up contents on any machine – but that’s another story).
As the performance of older Macs would not be harmed by a unlimited undo, I don’t see a reason not to enable it by default and forget about that “disable” checkbox.

Also, the manual should say that Undo is flushed upon save. This would avoid any surprises for new users.

If you take a look at the questions asked in the forum and in the mailing list, you could roughly estimate how much people actually read the manual. Therefore I think your suggestion isn’t really a good one. It may be the same if a car manufacturer writes a sentence in the car’s manual: “caution: the breaks doesn’t work if you’ve use the windshield wiper a minute before!” That wouldn’t be that useful.

I could be completely wrong here. But I would like to discern whether unlimited undo is mostly a luxury item which contributes to bloat and forced hardware upgrades. This is a serious issue for people who oversee underfunded school/academic labs. It is also a big problem in places which are lucky enough to have an old donated computer. And my mother (pauses, smiles fondly) would freak out if she had to buy a new computer.

As written above, nobody that could run Mellel today would have to buy a new machine because of a unlimited undo feature. Did you know, that the Mellel icon in your dock (assumed it is in your dock) uses 5 times the disk space than the 154 pages text mentioned above? So you should rather delete this icon instead of being frightened of a unlimited undo.

When is a good time to clear the Undo Buffer? How about when you save to disk? This is the current behavior, and I think that it takes advantage of the psychology of users and their tendency to save frequently. Therefore, I suggest to those who must have "unlimited undo" do two things: 1) increase the time between autosaves 2) stop hitting Apple-S all the time.

The question should be: why should the undo buffer be cleared at all? As explained above, the users like to be sure, that everything that they’ve written will be securely stored. That’s why they hit Apple-S and that's why they tend to decrease the time between auto-saves or backups. The possibility to undo a action, a word, a sentence, a change or something else is something completely different. It may be possible to clear the undo buffer, if a user hit the “save milestone” or ”save final document” command but most saves or auto-saves aren’t done because the saved document shouldn’t be modified anymore but to save (protect, backup, secure) the lines that have been written. Therefore it isn’t a good idea to clear the undo buffer in such cases.

I'd rather have Mellel act as it does now, but implement a versioning mechanism - which could be as simple as just setting back the clock to a previous [saved] version. I hope Time Machine would allow the developers to implement such feature with relative ease.

If versioning is out of the question, then (optional?) persistent undo would be a consolation price.

As far as I know, TimeMachine only copies modified files once a day (maybe that could be changed) to the external hard drive. With such a low frequency, it’s hardly possible to build a good and useful versioning feature. But I like the idea of flying through the time and browse back to see the whole undo history and saved milestones (versions) as well.

this page that says: “In just about all applications the undo history is lost the moment you close the document. There is really no reason for this since the undo history (if it is properly implemented) hardly takes up any space, and there is no guarantee that you won’t need it at a later time.”

The linked text contains some nice ideas that would fit in a word processor as well. Even if I don’t like the way the undo/milestone history is displayed, I think the idea behind is the way to go. Especially the branch thing could be really helpful.

That’s my comments so let’s got to the wishlist

[Mart°n]

My Wishlist:

1. Working undo buffer
I would like to see the undo buffer not being cleared during a save, auto-save or backup save of a document.

2. Unlimited undo
Given todays (or yesterdays) hardware, it shouldn’t be a problem to implement a unlimited undo where a user could browse back to the empty document. The undo history might be saved as a per document history inside the Application Support folder. By doing this, the undo information won’t be stored inside the document itself and therefore couldn't be read by other people than the original author. It would be ideal, if this undo information would be saved in short intervals of – let’s say 1 to 5 minutes, so that the very same file could be used to restore a previously saved document if the computer crashed before the document was saved. As only new items should be appended to the file, saving a snippet to the undo history shouldn’t be noticeable by the user which means, that Mellel should not pause some seconds as it does now when you save the whole file. Saving the history on a local disk also doesn’t slow down Mellel if one opens files via a network connection.

3. Usable undo history
Saving a undo history is one thing, being able to use it will be another. I think a usable undo feature will require something like a undo browser. TimeMachine is one possible interface for such a thing but there could be more optimized ones. Maybe a visual history (inside the outline sidebar) of undo actions and saved milestones would do the trick. Also a wheel or a slider to browse those items will be necessary (as nobody wants to press Apple-Z 600 times). Also brances (as explained in the link from zoul) would be a good thing.

4. Track changes
When enabled by the user, the undo history should be saved inside the Mellel package and one should be able to work as a different user with the same document. So the undo history and the user interface could be used to track changes, done by different users, too.

5. Remove auto-save and change backup
As the written content will now be saved every minute (or so), a auto-save feature is no longer necessary. Also the backup option should be changed in a way, that the backup files will be saved by a background process, so that the user won’t be interrupted by a small pause.

[aechallu]

Martin: Terrific suggestions, I hope the Redlers are listening.

[hlb]

Another major update, and no change on the undo front. I think at this point it's clear that the developers are stubbornly holding on to their product's fond little atavism. It was nice to play with Mellel for a while, it's a decent attempt at a professional word processor, but, alas, no more than that. I'm heading back to Word with all its weaknesses—and strengths.

[Mart°n]

Another major update, and no change on the undo front. I think at this point it's clear that the developers are stubbornly holding on to their product's fond little atavism.

The team of Melle developers isn’t that big compared to the Word team. Every update could only fulfill some enhancements which were planned some months ago. You could not expect to see a feature that was recently discussed in the nitty & the gritty forum to arrive with the next update. I started to work with Word in 1995 or 1996 and it took Microsoft several years to allow to color your text with some other than the 16 DOS standard colors.
Word may fit your needs better than Mellel but I don’t think the developers are stubborn because the feature you like most is not being released when you prefer it to be.

[joewiz]

Another major update, and no change on the undo front. I think at this point it's clear that the developers are stubbornly holding on to their product's fond little atavism.

The team of Melle developers isn’t that big compared to the Word team. Every update could only fulfill some enhancements which were planned some months ago. You could not expect to see a feature that was recently discussed in the nitty & the gritty forum to arrive with the next update.

Well said -- you can be sure that the Redlers consider good suggestions and implement them when it makes sense to given their development plans for Mellel. At the same time if a product doesn't have the feature you need, don't use a product just because you hope it will someday gain a feature -- particularly one that has only been suggested recently (or is the MS Office team more responsive?) and hasn't been publicly stated to be in development.

[nvalvo]

What if, while we're talking about the Undo buffer, said buffer were accessible by a pallette similar to Photoshop's history palette? So you could undo edits you had made in the past without undoing all subsequent changes.

That is to say, a full-fledged versioning implementation, probably in conjunction with a "Track Changes" feature.

I would call it "File History," however. I am imagining the interface for it now. It would look like the bibliography pallette, except with two panes. One would be a listview of edits, scrollable. When each was selected, it would display the edit, and optionally, the name of the user had made it and the time it was made, color-coded with green for insertions, and red for deletions. Buttons (with key shortcuts) would allow navigation, approval and reinstatement of changes.

This could be hot.

[drleper]

I'd like to see an unlimited session undo, meaning that as long as you have Mellel open, you can undo/redo right back to the beginning and back again, whether you've saved or not. However, once you save and close the program, the undo buffer is erased. Next time you open the file, the undo buffer starts from that point. The buffer would not be stored as part of the file, rather as temporary files on the computer.

I think this is how it should work, the current implementation of erasing the undo buffer on save is potentially dangerous. As possible scenario is some text was inadvertently deleted/messed up without knowing (say more text was highlighted than you thought and you typed over something), you save, at some point you discover the text gone and you can't go back to retrieve it!