Capture buttons' behaviors

[grahamas]

When you start a new capture, there is no way to back out without saving the capture. Pressing "< Capture" saves whatever is written (or not written) as if you had pressed "Done." On the other hand, as far as I can tell, "Done" doesn't do anything useful.

A more expected behavior would be for "< Capture" to discard the current capture and return to the Capture menu. I suspect that's too aggressive and might break usecases of established users, so a somewhat reasonable compromise would be for "< Capture" to discard the note if there is no text in the capture.

A more expected behavior for "Done" would be either (a) to save the capture and back out into the capture menu, or (b) to save the capture and start a new capture automatically. I would favor the latter for quick successive capture entries, but notice it would only work if the "< Capture" behavior is changed.

As it stands, the Autocapture mode makes the app somewhat unusable for anything but the case where you exclusively use the app for capturing. Personally, I would use the app 90% of the time for capturing, but whenever I want to view the TODO list I'd rather not go through the hassle of deleting the blank capture I created. (The "hassle" of three taps, I'll grant you, but in appland that's crazy).

[DivineDominion]

Unlike editing forms for submission, where discarding the data with a Cancel nav button makes sense, that would be weird for editing files.

I’d opt for

• simply removing the Done button like other editors do when editing
• add Cancel to the right (! not where the non-destructive back button is usually) when adding a new capture

[grahamas]

That would make sense to me.

I hadn't thought of it as editing a file since I always use it just to create the note, but of course you're right that in general that same window is also used for editing notes, so it wouldn't make sense for the back button to discard a pre-existing note you're editing.

[DivineDominion]

I played with the app around some more. What I said holds true for Captures. When you edit item bodies in outlines, though, you can argue that you do have a form-like situation and want to be able to discard changes. I think that'd be reasonable, but the MobileOrg team may disagree :)

[mgmart]

If an already existing capture is edited there should be an cancelling option.

[DivineDominion]

I think Cancel & Done make sense when you are about to create a new "Capture". But for editing? There always is undo when you make mistakes while you type. (A dedicated undo button seems to be the new cool, by the way.) It's only an assumption: I think people rarely start editing an existing note and then want to cancel the whole process, rather preferring auto-saving of changes they make. (For what it's worth, a cancel button also is less consistent with existing iOS apps.)

[mgmart]

From my point of view existing captures are item bodies residing in some kind of inbox.

Having the option to use an undo button seems fine for me. Using undo and then back would result in cancel, wouldn't it?

[DivineDominion]

Yes, it would. Also, no "shake to undo" required, which I always found odd :)

[dive]

I think that this is a bad idea to straddling two worlds. MobileOrg as an application to handle notes and to work with notes, so, let's follow the rules for notes and in-place editing (Notes.app is a good example). In this case, it would be easier for users to work with it because the UX will be familiar. There are no reasons to mix different patterns.

I propose the following changes according to the discussion above and #193:

• Remove the Done button from the capture screen and keep only the "+" button to create a new note quickly;
• Do not save the note if it is empty;
• Use system-wide UX solutions for the Undo (double-tap with three fingers, swipe left with three fingers to Undo, right for Redo on iOS 13 or "shake").