From vs To field ordering changing (depending on whether a transfer txn is inbound or outbound) is confusing and error-inducing

Bug #2017625 reported by Jeff Fortin Tam
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Maxime DOYEN

Bug Description

Homebank 5.6.3 on Fedora 38 with GTK 3.24.37.

When editing (or adding) inter-account transfer transactions, with "To" and "From" bank account fields, the order of those fields in the GUI depends on whether the transaction is positive or negative (inbound vs outbound), and this is super confusing. I never get used to it, I keep making mistakes and mixing things up because the constantly changing positions prevents me from developing any "muscle memory" on this.

Positioning should be consistent, have spatial persistence, like physical objects. My mind always intuitively defaults to thinking that it's always "From first/above, To after/below", since we typically flow from top to bottom (pretty much universally), and left to right (in north-occidental cultures).

I would therefore much prefer if the UI's ordering of those fields could be static, always be the "From" account on top, and the "To" account below it. Or if you want to make their visual relationship more evident, maybe they could be on the same row with different cells/columns, where "From" would always be on the left and "To" always on the right (when GTK is set left-to-right; otherwise needs to be tested with LANG=ar_LB.UTF8 for example), which could even allow using a unicode arrow if we want to be extra clear visually, i.e. the "To:" label could say "→ To:" maybe... but that's just an idea.

Bonus idea: having some sort of "Swap" (↔) button to easily switch the two fields around when the direction of the transaction is incorrect.

Revision history for this message
Lindsay Lorden (ludwigwn) wrote :

I an't reproduce this in my Windows 10/11 environment. Is it a difference in GTK levels or Operating System differences, or something else causing it?

I'm using: HomeBank 5.6.3
Running against GTK+ 3.24.33

Maxime DOYEN (mdoyen)
Changed in homebank:
importance: Undecided → Low
Maxime DOYEN (mdoyen)
Changed in homebank:
importance: Low → Wishlist
Revision history for this message
Maxime DOYEN (mdoyen) wrote (last edit ):

@Lindsay: no, this is consistent within OSes, but for now when you have an xfer of $10 from accA to accB
you have 2 txn:

(txn1) -10 in accA +linked to (txn2)
(txn2) +10 in accB +linked to (txn1)

this is not visible for the user but in the txn dialog:
for standard txn: you have a couple of widget amount+account with fixed position
for xfer 2 additional widget: xframount+xfraccount

when you edit (txn1)
- amount=-10
- account=accA & label='From:'
- xframount will be -amount (if same currency it is hidden)
- xfraccount=accB and label='To:'

when you edit (txn2)
- amount=+10
- account=accB & label='To:'
- xframount will be -amount (if same currency it is hidden)
- xfraccount=accB & label='From:'

But indeed the position in the ui don't change, so you have a swap of the From/To
to me it is logical, and technically also, has we edit the value of the from/to txn
but like JFT said this confuse his mind, which I may understand.

for example MMEX has also have static field for this, whatever you edit the src or dst part of the xfer
so I'm thinking to manage this swap internally with fixed widget position/order

Maxime DOYEN (mdoyen)
Changed in homebank:
assignee: nobody → Maxime DOYEN (mdoyen)
milestone: none → 5.8
status: New → Confirmed
Revision history for this message
Kinnin Vo-Shay (vo-shay) wrote :

This has affected/confused me in the past as well, and was a secondary reason I submitted bug #1867979 asking to show both sides of the transaction.

Having an internal transaction presented to the user in a consistent fashion, regardless of which context it is opened from, so that all the fields AND their values would be the same, would make editing and handling of them a lot less user-error prone.

Maxime - from your comment, it sounds like you've understood the issue! :D
I just wanted to re-raise the idea that date handing would probably also benefit from the design improvements you come up with here.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.