Enhancement: Make difference between list/find view clearer

[INCENDE]

Commands:

1. add hello
2. add world

2a1. find hello
2a2. undo
world gets deleted

2b1. list
2b2. undo
world gets deleted

[rachx]

Isn't this intended behavior?
find, list etc does not change the task list and cannot be undone

[INCENDE]

Yea but lets say i'm a user, i want to undo this list view, but ends up deleting the task instead

[rachx]

I never intended for undo to be used for list/find (display commands)
@burnflare ?

[burnflare]

+@fanwgwg

Philosophically undo only reverses a command that performed some kind of write operation. So I think @rachx has a point here and what we're doing currently is right. Any operation that involved any writes = you can undo that. Perform a read operation = no undo for that.

But, @INCENDE does have a valid point that we don't have a clear indication to the user that when they type "list" they've been brought into a separate context and how can they get out of the context. If I was a new user and I type "find ", then suddenly all my normal todos disappear from the list suddenly I'd be shocked and think I accidentally deleted something. And then I'll try to type "undo", which undos the last write operation and leads to even more unexpected behavior.

Stepping back, I think the real problem here is contextual awarensss. We need to make it clear to the user "Hey now you're in the FIND CONTEXT. Don't worry you're data is still existing in the NORMAL CONTEXT. You haven't lost data. If you want to go back here's how to go back". So let's solve that problem.

Here's my crack at solving this problem: Whenever we do something that changes context (find/list), we make a subtle but noticeable change to the entire command box UI. Something like highlight the entire command box in yellow and hover text on the right corner of the command box saying "Showing find/list results. Hit "esc" to return". We're making it clear to the user you're in a different context + giving clear direction on how to quickly go back by hitting Esc.

Thoughts?

[rachx]

It probably needs to be clearer in the user guide and help command window.
We can make use of the space on the top bar (file and help) to show that this is a search result.
Press esc will call model to update filtered list to show all again

[INCENDE]

I think both ideas are great.
Editing the command box might not be a good idea though

[burnflare]

Here's my mockup of the feature. In normal mode the app works exactly as it does right now. When you're in find more, a single line bubble animates between the results and command section showing a bubble with that test. When you you exit that mode, this bubble animates away and the command and results window joins again. @fanwgwg possible?

This would be super obvious to that user what's going on

[fanwgwg]

I am wondering why not just give the result pop up window such a message after the user types "find"?

[burnflare]

Nope, it should be persistent. We're conveying a permanent change in state, not a notification that something has happened.

[fanwgwg]

So do you mean that the user should not stay in the state after the found tasks are shown? But more commonly I would say the reason why user want to search for some tasks is that they want to perform some operation on these tasks, like mark/unmark/schedule/delete, rather than just to give these tasks a look.

[fanwgwg]

Why not just don't save the current list if the command is find, I think this makes more sense.

[burnflare]

Yup we're already doing that right now: when we do a find, we don't save the current list. Functionality wise we're doing everything right here, nothing to change. We're discussing the usability problem right now.

[rachx]

A possible solution will be to bring the command feedback back to the main window (instead of having a popup). Then, a message such as "here are your search results for books" will stay there

[fanwgwg]

@INCENDE @burnflare @rachx can check whether my implementation is okay? #173

[rachx]

Resolved :)