Add user coefficients.

[Korri]

We currently use an App on Android, and is has a realy cool feature, you can assign a default percentage to each user (default and per transaction), so for example we have a couple here so they have a default percentage of 200% as they share the same money (And like that we don't need to split every purchase between the two of them).

Having this feature could be really cool.

[almet]

We already discussed that internally, and the answer, basically is that we want to keep things simple. At this time, I couldn't find about a simple way to implement this, but now I'm getting a better idea about that: we could simply add a coef for the users, at creation time.

Would that work for you? Also, do you want to work on this or is it only a feature request? (both are acceptable to me)

[QuentinRoy]

We have to be very careful about the added complexity on the overall interaction. How are we doing to set this? Are we thinking on adding a popup at each account creation? Or perhaps an "advanced" hided frame? Moreover how can we indicate to user which account have a coef ? A small mention like

the guy (200%)

in the balance could do the trick.. But I'm not sure it is easily understandable and even hidden when unused, it may be a little bit noisy..

Also, it then implies that it has to be fixed, right? Isn't it simpler in this case to just create two participants even if then, only one of then can pay at a time ?

If this coef can be modified (it would better match the use I would do of it) where can we do it? Perhaps it will be better at the bill registration? But we it would be boring to add it each time for the same person. And the form is already quite long.. Such optional parameter shouldn't disturb the usual registration. Perhaps the coef could appears on hover. Less discoverable, but less noise too.. And how can we display it then? In the bill list? IMO bill lines are already too long, I was thinking on what we could hide.. In this case, such mechanism will become mandatory I think.

[Korri]

It was more a feature request, but I might find the time to work on it (might take some time though as I never looked at the source of the project).

Tinmn I understand the want to keep it simple, for me a default AND per transaction coef is mandatory, but it could be added quite silently :

• It you know tricount, they have a "details" links that just adds an input per user to define the coef.
• The default percentage doesn't need to be visible all the time, the hover behavior you describe is greate
• I agree on the list, but maybe juste a (100%) or (x1) near each name in the "For whom?" column wouldn't be that anoying

And maybe the possibility to enable/disable this functionallity on a per project basis could be cool ans satisfy everyone

[QuentinRoy]

Hmmm. Sorry. Here is another proof that this github "close" button is a big usability problem.

Don't think I'm against the idea (not at all). It is just that I want to make sure than, when adding a new functionality, we think carefully on all its implication on the global interaction with the system. It always raises a lot of questions (even for the simplest things) and often requires to rethink the whole interaction with the system.

[aavenel]

Just my two cents :

I'm a bit concerned about this request because I think that one of the best features of ihatemoney is NOT having this kind of option to "keep it simple". But if we could manage to integrate it properly I agree this could be useful.

I don't really see the need for a default coefficient. You gave an use case about a couple but maybe it is easier to add two persons. Then it's just one click to add another person for each bill. Perhaps the real usability problem here is because the "Add a bill" panel is too long and you can spend a lot of time to find the corresponding persons. There is already a lot of good ideas to solve this in #64. I don't see any real improvement with this feature, and it will clutter the global interface. Moreover, we already have a lot of interaction with the hover behavior.

However, I totally agree that the coefficient per transaction would be nice to have. Example : you're at the restaurant, one person pay for all. You can type the amount of each meal as a coefficient and everyone will pay the right amount (And if the coefficient field could handle additions and percentage this would be perfect !)

[Korri]

The need for default coefficients will show if you ever implement the pull request #84 wich is a must have in my opinion. I agree that I hate money is simple and pretty easy to use and that's why I love it and it should stay that way, but right now my shared Google spreadsheet has more features, and is not really harder to use (Not provocating or anything, just a fact), that's why those features are a Must Have for me.

[almet]

Google spreadsheet is a closed source tool, so we can't make comparisons here.

84 is a different one, someone just needs to take the time to review and update it according to the codebase we have now, but we're fine with it. Let's keep the discussion there to not mix everything.

This one is very different: a lot of people will just not need it, and having a way to handle this could lead them to not understand the tool, or to add unneeded complexity. That's the point everyone here made.

If you can come up with some mockups or ideas to make this not intrusive, I think we can come to a solution; feel free to do so, but so far we just have people opposed to the idea of adding complexity to the interface, and no-one to work on this particular one.

[aavenel]

First attempt to design the UI :

By default, we show the amount to pay for each person. When you click on this amount, you can edit to another value. If you type a value with a "%", the value should be considered as a percentage. Comments are welcome !

[almet]

Thanks,

I'm not sure to completely understand: what does the percentage mean here? is it 60% of the total? how can we have 60% + 40% + 20?

[QuentinRoy]

I agree with Alexis.

I quite like the idea to see how much everybody "will pay" (not sure it is the good term however, owe perhaps) directly from the bill form. I think it is important there when not everybody owes the same.

However perhaps we need a little emphases on the name then. It adds a lot of noise.. What do you think? Did you try to display the "will pay bla bla bla" in lightgray in order to make it more discreet (this is secondary information)?

[aavenel]

Sorry, it wasn't very clear. I'll try to explain differently. In fact this mockup tried to mix two features : coefficients (percentages) and custom amounts for the same bill. After all I'm not sure we need coefficients, I don't see a real use case for these.

However, I suggest to add a way to divide a bill. For example you're at the restaurant. If everybody ordered a different meal, you should be able to put different prices for each person. We can use something like the previous mockup for the UI.

[almet]

I think this makes sense, yep. could work for me.

[berteh]

plus 1 for the coefficient idea. Personally don't care if it turns out as percentage or [1.0] figure. I use this app for tracking expenses in groups of friends, and each of us is actually a familly.

basic example. Fred (is actually Fred + Mary) -> 2.0 Jimmy (Jimmy +1 kid) ->1.5 Coco (on her own) -> 1.0 (default, no mention) Edgar (+wife & 3 kids) -> 4.5

To keep things simple I'd suggest to put default coeff of 1.0 so that new users don't need to care, allowing to change it at the project level if wanted. To then use current "project-level" coefs by default for new transactions... allowing the user to make a different choice at time of encoding if needed (either in terms of coef or plain figure).

working example at http://www.bonscomptesentreamis.com (in french), along with nice balance export (incl pdf).

hope this helps. Thank your for contributing to interesting opensource code!

[almet]

@berteh yeah that makes sense.

@aavenel do you want to have another go on this one?

[almet]

Where are we with this? @aavenel do you want to work on it?

[almet]

Another possibility is to add this coefficient information to the list of people (e.g. that would work for couples).

This seems to minimize the complexity (no change when adding the new bills) and could only when editing the users (not sure exaclty how to do that, though).

[JocelynDelalande]

+1 for the proposition of coefficients on users, I think it's a rather light feature in terms of UI, for same reasons that @berteh mentioned.

Another use case, which is quite complicated to handle without software and fits nicely with user coefficients :

• John, Mag and Bob go on holidays together
• John stays 3 days, Mag 2 days and Bob 2 days, they log their bills on IHM.

Assigning weights based on the days people stay is a nice way to handle that (doing it with spreadsheet is not straightforward).

IMHO we are discussing two different features : in-bill coefficients and user coefficients. @ametaireau (or any spiral op) could you take decision to rename the ticket for one of the feature and issue another to split the features ?

[almet]

I've updated the title of the issue. I think the other proposal (in-bill coefs) is a no-go based on the feedback we currently have.

[JocelynDelalande]

I started working on it. As it implies schema modification, one question that remains IMHO before merging is how to handle migrations, see https://github.com/spiral-project/ihatemoney/issues/83

[JocelynDelalande]

UI proposal for users list

I suggest hiding the coefficient if everyone is x1

[aavenel]

Looks good for me, but how do you define the coefficient for each user ?

[JocelynDelalande]

Looks good for me, but how do you define the coefficient for each user ?

Coming later, work in progress :)

[JocelynDelalande]

UI proposal for the users list to access member form (on hover on user)

[zorun]

I guess this issue can be closed, it has been implemented by #131 :)

[berteh]

love it, and the simple way you handled it. congrats.