jesse wrote:Patzer, I'm starting to get your concern with the persistent state -- the main problem being not knowing what's "active".
That's the biggest concern, seeing the selection and not knowing whether pressing delete will delete it or not. A lesser concern of mine is the "leftover" selected transaction that the user forgets about, resulting in the deletion of that transaction by mistake when the user pressed delete, or inadvertent opening the transaction for editing when the user clicks on it intending to select it. I've avoided this by become anal about de-selecting transactions, but I read that other people have been bitten.
jesse wrote:It's especially noted when dealing with the Scheduler and when clicking in the transaction-less area in the Register (or Scheduler). I'm not convinced about moving to the Budget and then back removing selection.
Dealing with the scheduler is the real nightmare of knowing what's active. Clicking in the transaction-less area is an ongoing low grade nuisance. In Pro, I learned to do this habitually to select none, so that functions like mouse over date for balance would work. In YNAB 3, I still find myself tripping over the fact that this doesn't de-select anything.
If you're going to leave transactions selected when I navigate to the budget page and back to the register, you need to give me some visual cue as to whether the transaction is really active or not. Otherwise, we still have the issue of not knowing. I continue to think it would be better to automatically de-select when navigating away from the current register in any way, because otherwise we still have the issue of unintended actions on the leftover transaction that the user forgot about. Besides, the real need for having a bookmark was to be able to find where we left off in the early beta versions. That's not nearly as important since some of the early sorting and navigation issues were cleaned up. I also notice that the bookmark type function is far less important to me when I'm using YNAB to do my budget in working mode, as opposed to playing with YNAB in test mode to see how it works and what I can break.
Another low-grade annoyance that might be related to persistent selection, or might only be what I'm noticing at the same time, is that F5 to sort doesn't work after I deselect the transactions. So my most convenient form of data entry--enter to accept the default, then escape out of the new transaction to select none--doesn't allow for me to press F5 and immediately sort the newly entered transaction into the correct order. I have to select something, then sort, then de-select. I'm not sure what the best way to address this would be, but some thought probably needs to be put into when F5 does and does not work and when it should and should not work.
Okay, I had to do a test. If I enter a transaction with an earlier date than the latest existing transaction, then de-select everything:
1. F5 does nothing.
2. Navigate to budget page and back to same register finds same sort order, F5 doesn't work.
3. Navigate to different register and back sorts the transactions.
There probably needs to be some thought put into what ought to happen on navigating away from the register and navigating back, and it probably should be consistent regardless of whether you navigate to the budget or to a different register.
Patzer
