tldr: Revamped keyboard bindings for the transaction table
New keyboard bindings
This update focuses on keyboard bindings. We are getting closer to a well-defined and consistent experience, and I'm optimistic that these new bindings will work for the long-term. Previously, tab & enter were slightly different (tab saves values from text inputs, but not if you've selected an item from a dropdown, while enter does). Shift+arrow keys moved around, which conflicted with the text input editing. Here are the new bindings:
- Tab/enter are exactly the same. It moves to the right, and saves the value. If you've selected an item in a dropdown, it will always be saved.
- Shift+tab/enter behave the same, except it moves to the left
Those are considered the "core" bindings that a lot of people will use. Since pressing tab at the end of the row will move you to the first field in the next row, it allows you to quickly go through transactions and update each field on the way (like updating the payee, categorizing, and then tabbing through to the next transaction).
There are more advanced bindings when you want more powerful navigation, enabled by Alt:
- Alt+enter moves down (to the next row)
- Shift+alt+enter moves up (to the previous row)
- Alt+arrow keys move in any direction
I don't think these conflict with any existing keybindings that users would use. While it's not as easy as a spreadsheet, it's a good compromise, allowing users to use them when needed but still keep the clarity and simplicity of focusing cells.
I played around with the idea of having enter/shift+enter move up and down, but it was far too confusing. The fact is, this is not a spreadsheet and is much more like a database. Users naturally want to hit "enter" to select an item in the dropdown, and early testers found it confusing that in those cases it moved down (when they wanted to move right). Even worse, when users would hit enter instead of tab when adding a new transaction, they would move down into the transaction table and be confused again.
I also explored the idea of a true spreadsheet-style modal editing system, where users can activate a mode where cells are "highlighted" but not being edited, and arrow keys move around, and pressing enter starts "editing" a cell. The complexity for this was not worth it, as again, this is not a spreadsheet and users not familiar with spreadsheets should not feel scared of it. It's extremely important to me that users new to editing data feel welcomed and are encouraged to use it. Clicking cells, making it clear that they can type data, and pressing tab/enter to save and move to the right is core to that simple and welcoming experience.
Various bug fixes
Several minor internal bug fixes and cleanup has happened to prepare for future features. Things to note:
- The net worth graph had a regression where it always drew a line, even in the positive range. This was due to a bug in a dependency used to render the graphs. This is has been fixed and will now render blue for positive amounts.
- Split transactions will always keep the order in which you added them. Previously this wasn't guaranteed.
Tests
Lastly, much of the time over the last week was spent on something that users don't see: UI tests. A lot of tests now ensure that the app is functioning properly, which will prevent regressions in the future and allow us to continuously ship a stable app that is evolving forwards.