Split Transaction UX

[derei]

Split transaction seems either buggy, or unintuitive.
Simplest way to explain would be by screenshots:

Split transaction with the sum of the parts greater than the whole (available: 50, splits sum: 55).

When attempting to save, the error warns about unsplit amount.

Values were corrected to sum 50, and now transaction can be saved.

The saved transaction can be edited however.

I modified the 30 split into 35 and I was able to save. Now the result shows -55.

I see several issues here:

• user isn't given the option to select the remainder when adding a split.
• error message is inaccurate and pottentially confusing.
• splits are allowed to be edited later to sum greater than the available funds for the split.
• interface and controls too small, making it difficult to tap on some features.

Mention: I am only dry testing the app for now, trying to figure it out.

[mtotschnig]

• user isn't given the option to select the remainder when adding a split.

You can click on the remainder in order to copy it to the clipboard (#806)

• error message is inaccurate and pottentially confusing.

It seems as accurate as it gets to me. What alternative do you suggest?

• splits are allowed to be edited later to sum greater than the available funds for the split.

Actually, we do not allow the sum of the parts to differ from the available fund for the split, but we update the sum automatically, which is a bug: #1349

• interface and controls too small, making it difficult to tap on some features.

The only element that I am aware of that do not respect the recommended minimum touch target size of 48dp are the rows in the part list. I am afraid, doubling their height would make the interface look quite far-stretched.

[derei]

@mtotschnig
Well, telling the user there is "amount left unsplit", when the splits are in fact greater than the available funds is not verlogical, is it? It suggests there are still available funds. Whereas the reality is that available funds should be increased to allow a larger split.

Maybe not doubling the row height, just consider a more touch-friendly approach? In general the app is quite touch friendly, except few details which I believe arise due some design inconsistencies.

[klaviartur]

@mtotschnig
Maybe "total does not match sum of parts" !?

[derei]

@klaviartur that's still too ambiguous because it doesn't tell if you still have funds left, or splits sum greater than available funds.

The current error tells "There is still some amount left unsplit", but that is incorrect when splits sum greater than available funds (entire amount has been split AND THEN SOME). But the error tells you there is more to split.

[klaviartur]

@derei
That's what the sign of the unsplit amount is for.

Your screenshot shows unsplit amount: 5, meaning 5 over budget. It there was funds left, it would say unsplit amount: -5
In a transaction with a positive total it would be the other way round.

It's simply and mathamatically: Total - Sum(Parts),

in your case: -50 - (-20 + -35) = -50 + 55 = 5

Yeah, I agree, it's not the most intuitive thing in the world, if you see it for the first time, but as a long time user I have to say that I had no trouble getting used to it immediately and never got confused again.

Would you like
"Sum of parts is greater than total" and "Sum of parts is less than total?"
This would be mathematically incorrect, since -55 is less than -50, but I guess mathematical preciseness is not what you are looking for here and "Absolute value of total is greater than absolute value of sum of parts" is kind of overkill 😉

[derei]

@klaviartur good design means you don't have to "figure it out" and getting it wrong the first time, even if you don't confuse it in the future.

You may not realise it, but the subconscious effort we put in using various apps and technologies nowadays is taking a toll on us. Unified design is not just for things to be pretty: its purpose is mainly to relieve the pressure of having to figure things out.

I would rethink a bit the UI/UX, rather than keeping my focus narrowed to a warning message. Can it be done different, so it doesn't need the error message, but inform the user in a more direct/intuitive way? Most probably. But it would require some brainstorming.

[klaviartur]

@mtotschnig
i was about to open a fresh issue regarding split transactions - that's how I stumbled over this one - but as my point is very similar to @derei 's first one, I'll post it here:

If total is already set (i.e. not calculated automatically from parts), it would be very nice, if the amount field of every new part was initialized with the remainder. As it is the selected field to type into anyway one can either type a different amount or keep it and change everything else. This would be more streamlined than #806
As a bonus you could then autmatically deactivate "save & new" on new parts as soon as total is reached.

[klaviartur]

@derei
(Mostly) agreed.

Let's brainstorm then.

From my viewpoint you can do one (or more) of three things:

1. make the difference between sum and total obvious at all times, including direction (too much, not enough)
2. prevent saving as long as there is a difference and inform the user, why saving is not possible
3. automatically change the total to match the sum

I think, we can agree that no. 1 is desirable in any case and we additionally have to choose between 2 and 3.

Now, how to do no.1?

As we agree that the pure maths and the needed and interpretation of the sign of the difference is unintuitive, how about using words?
Instead of static text "unsplit amount" it coud say "oversplit amount" when absolute value of sum is greater than absolute value of total.

Sidenote: the mathematical implementation is even more complicated than that, because parts can have opposite sign from total, but I won't go into the details here. It is solvable anyway.

Another Sidenote: In german I would suggest "Unverteilter Betrag" and "Überverteilter Betrag"

The sign of the difference would then have to be always the same as the sign of the total or omitted entirely.

As for the choice between nos. 2 and 3, there has been a decision in #497 to not automatically change the total, which is sensbile in my opinion. But of course one can reevaluate the option of asking the user whether they want to recalculate the total.

In any case you cannot just not save without an explanation. If not a error message then there has to be another hint, why save cannot be applied, e.g. highlighting/flashing of the previously described line "unsplit/oversplit amount".

One could even grey out the save button while there is a difference (and still give message or highlighting difference line when user taps it anyway)

Your thoughts!?

[derei]

@klaviartur @mtotschnig I believe it is going in the right direction. Building on what you proposed (and going back a little), I suggest:

1. The = sign on the splits to be replaced with an icon something like a pocket calculator - it's more intuitive. I only tapped by accident on the equal sign, or else I would have never guessed it has a funcionality.
2. Make the split rows slightly taller and reduce the tags row. The notes row should be dynamic (1-3 rows, based on content)
3. When adding a new split, the app moves to a new window, taking away some crucial visual information: total funds, remaining, funds, existing splits. Moreover, there is an entire empty screen just wasting space.
   Perhaps that can be mitigated:
   - either add the relevant information to the new split screen.
   - or, instead a new screen, use a dialogue that pops over the main screen, still allowing to see the splits table.
4. Regarding the actual issues discussed here, and the suggestions made by @klaviartur , perhaps we can optimise it as follows:
   • if one attempts to save without splitting all the funds, a dialogue with two options to be presented:
     -- Add the Remainder Automatically (as Remainder, or whatever should be automatically named), and save;
     -- Go Back to Edit.
     If you think about it, there isn't another option. Increasing the funds means editing. And is best if the user operates such sensitive edits, to maximize intentionality.
   • if the user attempts to save when sum of splits is greater than available funds, the popup dialogue should present two options again:
     -- automatically adjust last split
     -- Increase funds to accomodate last split (or go back to Editing, to maintain logical consistency?)

What do the above achieve:

1. Provide immediate action options with the warning.
2. Reduce the amount of interaction gestures.
3. Keeps the information in front of user's eyes at all time.

[klaviartur]

@derei

While I appreciate your fresh outside view on the app and can only agree, that an equal sign does not make me think of a calculator, I personally feel your demands are quite far-reaching and as such do not have a great probability of being implemented soon.

I personally like to salvage quick wins which give most of the improvements with minimal effort.
In this case changing the static text as describes in my no.1, increasing split row size a bit (@mtotschnig why would you have to double it?) and of course this point

@mtotschnig i was about to open a fresh issue regarding split transactions - that's how I stumbled over this one - but as my point is very similar to @derei 's first one, I'll post it here:

If total is already set (i.e. not calculated automatically from parts), it would be very nice, if the amount field of every new part was initialized with the remainder. As it is the selected field to type into anyway one can either type a different amount or keep it and change everything else. This would be more streamlined than #806 As a bonus you could then autmatically deactivate "save & new" on new parts as soon as total is reached.

will have the most gain per effort.

In the end, we are just users, of course. It is up to @mtotschnig to decide what to do.

[derei]

@klaviartur those weren't demands, but suggestions. In the end, the app development will go the way the developer(s) want it to go.

Best, and good luck!

[mtotschnig]

@klaviartur @derei Thanks for sharing and discussing your inspiring ideas! I'll take them up one way or the other, but will need some time to navigate the trade-off between effort and available time. For the moment, just some quick thoughts:

• I agree that the message "There is still some amount left unsplit" is not obvious in case of the sum of the parts exceeding the transaction amount (This had also been mentioned in Undistributed sum in form for editing split is not obvious in some cases #671). But want to add that technically the "oversplit amount" is still unsplit, because it can be accounted for by adding a split part with the opposite sign (as @klaviartur has hinted at).
• I'll replace the equal sign for the calculator with this one
• The row heigth of the split list is currently 19dp. For respecting the recommended minimum touch target size of 48dp, it would need to be more than doubled.

[derei]

@mtotschnig You could try 32dp for the row... perhaps it will suffice without spreading things too much.

[mtotschnig]

@mtotschnig You could try 32dp for the row... perhaps it will suffice without spreading things too much.

Good idea. I will try that.

In version, 3.9.4, #1349 will be fixed, thus addressing the third point of the original list.

[klaviartur]

@mtotschnig i was about to open a fresh issue regarding split transactions - that's how I stumbled over this one - but as my point is very similar to @derei 's first one, I'll post it here:

If total is already set (i.e. not calculated automatically from parts), it would be very nice, if the amount field of every new part was initialized with the remainder. As it is the selected field to type into anyway one can either type a different amount or keep it and change everything else. This would be more streamlined than #806 As a bonus you could then autmatically deactivate "save & new" on new parts as soon as total is reached.

Would like to kindly bump that as I fear it might get overseen in this rather lengthy thread and it's very important to me and also seems to be a minor effort.
Hope, I'm not mistaken.

[mtotschnig]

@derei

2. The notes row should be dynamic (1-3 rows, based on content)

The notes row's height is dynamically adjusting on my side. Could you post specs of the device and screenshot or recording of your mileage?

[mtotschnig]

3. When adding a new split, the app moves to a new window, taking away some crucial visual information: total funds, remaining, funds, existing splits. Moreover, there is an entire empty screen just wasting space.
Perhaps that can be mitigated:
- either add the relevant information to the new split screen.
- or, instead a new screen, use a dialogue that pops over the main screen, still allowing to see the splits table.

This is an excellent remark. Unfortunately the current design is due to a legacy architecture, that I won't be able to change reasonably soon. For the moment I will adopt @klaviartur 's suggestion (extracted to #1633) of initializing the edit screen for the part with the remainder, thus providing a minimum of that context information.