Problems with Undo Navigation

Another observation which may help:

  1. I made an edit in note “A.”
  2. I switched to note “B” to make another edit.
  3. Clicking my insertion point in B and pressing “return” elicited the jumping behavior already described. The cursor jumped up a few lines in B and added a new line above where I had intended. All this is as before.
  4. Here’s the new observation: Typing cmd-z (to undo the jump and insertion) in B, took me back to A!
  5. When I returned to B I saw that the “damage” in B had indeed been undone, but why send me all the way back to note A?
  6. I can toggle “undo” and “redo” and the behaviors just described are repeated.

This unexpected jump between notes has happened several times before and it’s very disorienting. If I’m not paying close attention, I lose track of where I was. Moreover, it momentarily causes me to worry that some large part of my Agenda database has suddenly been altered or deleted, although when I get back to where I was everything still seems to be there.

But, then again, how would I know if it wasn’t? How would I know if something really had been inadvertently changed? The whole point of an app like Agenda is to keep track of histories and details that my own memory is too crowded to retain. I’m relying on it — utterly — to remember things for me. If that app-based memory becomes corrupted, how would I know?

That’s why it’s so important for applications like Agenda to behave in predictable ways. It’s not just the reliability of the app — which may be 100% — that matters. It’s also the user’s experience of reliability that matters. It’s possible for a user to lose faith in an app, even though it hasn’t really failed in its essential functions.

I’m not saying I’m ready to give up — I have too much invested in Agenda for that — just that it’s psychologically important to me to get this fixed.

The behaviour of jumping back to the previous project when undo-ing the first edit after switching project is indeed a known issue and one we hope to fix in the future. It is however unrelated to the jumping cursor problem. @drewmccormack I do see the same as @len that it usually jumps back to the place you were previously editing (though not necessarily to the end of it)

It is actually difficult to get this right. What you see is not a bug, but how it was designed. We are considering how we might make it work better, but it is not trivial. I’ll explain why.

  1. You make an edit in project A in note 1
  2. You move to project B and make an edit in note 2
  3. You undo

What should happen? Clearly the change in project B should undo. The question is what should be shown? Do you now want to see what just undid, or do you want to go back to the relevant place for the next undo, in project A. If you hit undo again, surely you want to see what is about to undo before it happens.

So you see, this is not clear cut. It depends largely on what you want to do next, and we can’t really know that. If you keep hitting undo, the app surely has to go back to the places where the undo occurred, and that is what it is doing.

One solution to this is to have undo only work inside a single note. But then what do you do for undoing an inserted note, or a deleted note?

Since we are discussing it, I just took a look at what apple notes does. Indeed, it only undoes in a single note. Seems you can’t undo inserting a note. We would like to keep that possible.

We may be able to come up with some approach that works a bit better, but it is not simple, because we can’t really know what you want to do after the undo: do you want to keep working in that note, or go back to the one you were just working in before that?

Thanks for sharing your thoughts. FWIW, here are mine:

Undo is most intuitive when it undoes the last action the user took.

In your example, the last edit was in project B. The edit was the last thing the user did. Undoing the edit on cmd-z is the expected behavior.

On the other hand, the user switched to project B before making the edit. So, switching to project B was the second-to-last thing the user did. It’s not expected that cmd-z would undo this in addition to undoing the edit. As I reported above, it’s extremely disorienting to suddenly find yourself in another project after an undo operation. It’s as though Scotty suddenly transported you back to the Enterprise when you expected to still be on the planet.

The same would hold for two notes in the same project. If I’m in note 1 and then I switch to note 2 and make an edit, and then undo the edit, I would still expect my cursor to be in note 2 because the second to last thing I did was to switch to note 2.

As for undoing the creation/deletion of a note, I, too, am in favor of retaining this functionality. I’m a little surprised that Apple doesn’t allow it. If creating a note was the last thing the user did, removing the note on cmd-z would be the expected behavior.

What I believe should not happen on undoing the creation of a note, though, is for the user to be taken back to some other project. If the actions the user performed are, in order, (1) switching to the project and (2) creating a new note, then the last thing the user did was (2) creating the new note; cmd-z should not also undo (1) switching to the project. As you say, this is indeed what happens when I undo the creation of a note in Agenda. If I switch from project A to project B, create a new note in project B, and then undo, I find myself back in project A. To me, this is disorienting because switching to project B is the second to last thing I did. The last thing was creating the new note.

Yes, I certainly see your point. The problem though is this: you consider switching projects to be an undo-able action, and it isn’t. It is a navigation. It changes nothing. So we have to decide where that navigation fits in. It may seem intuitive not to navigate back, but that depends what you are doing. If you type a different word in 5 different projects, and then hit undo 5 times, my guess is you would expect to see each word before you undo it to remove it. See the problem?

But I certainly do agree it is a problem. We are discussing it now. I think I am for a much simpler, shorter undo history. We’ll see what we decide.

Yup. Thanks again for sharing your thinking. That openness, and the easily accessible support link at the right-corner of the page, sets Agenda apart from other apps and (hopefully) helps you develop the app in a way that avoids the kinds of blunders that have plagued Evernote.

To your point, then…

In general, I like the idea of having an undo history. If I’m editing a PHP file in Adobe Brackets, for example, I like being able to undo a half-dozen failed code changes simply by hitting cmd-z six times.

But in Brackets, the undo chain stops at the boundary of the file I’m editing. Once I’ve undone all the changes I’ve made to file B, cmd-z does nothing. Brackets does not navigate backward to file A and start undoing the edits I had previously made there. If I want to continue my backtracking in file A, I have to navigate to it manually. Then I have a completely different undo history specific to that file.

I have sometimes wished for a function that would sequentially undo all of my changes regardless of file boundaries. But the effect would be like a pinball machine, taking me from file to file without warning as it follows the undo chain in whatever sequence I made the edits. In retrospect, I think Adobe was wise to do it the way they did, limiting the undo chain to the current file.

In Agenda, the basic unit is not files, but notes. But the principle could be the same. The rule would be that undo operations are restricted to the note you’re currently working on. You can undo edits, or even undo the creation of the note, but the undo chain stops there, in note B, unless you navigate back to note A, in which case you have a separate undo chain specific to note A.

And, of course, if you quit Agenda and restart it later it’s a whole new ball game. The undo chain does not extend backward past the current session.

An afterthought: Perhaps if you want to retain the current functionality, you could assign it to a more complex key combination (cmd-option-z) or somesuch. But the normal cmd-z would apply only to the current note.

1 Like

This is pretty much the same as a discussion we had yesterday about it. I was thinking along the lines you mention: just have undo work for the current note you are editing. But that leads to the issue of how you undo inserting/moving/deleting notes. Not clear, if the undo ends at the editing boundary.

We also realised it is not entirely true that the note is the obvious undo unit. People are likely to think of projects as that unit, because it is not uncommon to have multiple notes on screen, and to move from one to the next, making changes. If you then undo, you would probably be surprised that it only worked in the most recent note.

So we think we will probably keep things like they are now, but with a very important improvement which will make it more natural and obvious what is going on. I’m working on that fix now. Hopefully will be in the next release.