Must enter Payment method twice in Add Transaction dialog

[tom ross]

Homebank 5.1-1 on Windows 10 64-bit and Arch Linux 64-bit (Linux 4.8.2-1, Gnome 3.22.0-1):

When adding a new transaction, the Payment method blanks out when you enter the Payee and you have to select the Payment method again.

From a continuity/user experience point of view, the order of the fields in the Add Transaction dialog is a bit wonky compared to previous versions.

[Maxime DOYEN (mdoyen)]

There is a new feature that enables and ease input to define a default category and payment for payee.
So it's now better to to preset this once, and then just input the payee at first (then change it if necessary).

There was no big changes on the transaction dialog, moved to 1 column and put status up 2 rows. It's like for any changes, little time is required to adapt. Please be more explicit on what is wonky there !

Max.

[tom ross (tomross123)]

Sorry, I didn't see the bit about defining defaults...

I found things wonky because in the two-column layout, I completed the fields sort of from left to right, row by row. Changing the layout to one column changed the order in which I completed the fields. Going from top to bottom I ended up having to go back and re-enter the Payment method field when I completed the Payee field (because I hadn't set defaults).

If completing a field sets values for other fields in the dialog, perhaps that field should be presented first, or at least before the other fields?

P.S. - thank you for a great product!

Tom

[Torben Schiffke (hoerbert)]

> If completing a field sets values for other fields in
> the dialog, perhaps that field should be presented first,
> or at least before the other fields?

I second that. I think it is UX-Horror, if changing one form-field changes the values of form-fields which already have been filled.

Either move the payee-field up or just fill the payment-field automatically if it has not been filled before.

> P.S. - thank you for a great product!

I also second that! Thanks for your effort!

[Bryan Quigley (bryanquigley)]

On my other computer (16.04 with AMD Graphics) it doesn't show the field switching back to None, so it looks like it's still set to whatever you set it to before. On this machine (16.10) it works as mentioned above.

Guessing it might be a machine specific graphics bug? - Will debug more later

[tom ross (tomross123)]

Just to clarify a bit more:

I have no default values set for any payees on either the Windows or Linux machines. It doesn't seem to be a matter of a default Payment method or Category being wiped when you select the Payee; it's more like an entered Payment method or Category being wiped by blank Payee default values.

[Bryan Quigley (bryanquigley)]

@tom ross
Same as me now.

The "not showing the change" bit, appears to have vanished after a save and reboot.

[Maxime DOYEN (mdoyen)]

I will check this, I may have missed to check emptiness for paymode first

[Maxime DOYEN (mdoyen)]

Now the behavior is :
- empty category and paymode = none is required for a payee change to trigger init with default value associated to payee.

which mean if you input paymode first with empty category, the paymode will not change, and if you input payee first, default value will be set for both category/paymode.

[tom ross (tomross123)]

Well, that sounds like it would work... I can't help but think it would have been easier (and better for usability and accessibility) to move the Payee field to under the date...

[Bryan Quigley (bryanquigley)]

@mdoyen
Thanks! That sounds perfect to me.

[Maxime DOYEN (mdoyen)]

@tom: I disagree, layout is organized like historically, with most important fields at first.

With not movong payee, people won't be disturbed, and are able:
1) as in the past -> input paymode/payee/category manually
2) or -> leave paymode empty (none) and when in payee, by selecting payee, fill in paymode and category as well