Study features and UX of tricount VS ihatemoney

[almet]

Most of my friends are using the paid, closed-source and ad-powered Tricount to handle their shared expenses, and I wonder why.

It's partly because it's a "well known" solution, but I do think there are other reasons, and I would like to list them in order to craft a good alternative to it. I don't think we should copy tricount, but I believe studying it could help us improve in some ways.

I haven't used Tricount yet, so I'm telling this from reading their documentation. We might want to install it and check by ourselves as well.

Here are some stuff that tricount does differently :

• Accounts : might be useful to browse existing projects. IHM doesn't have accounts because we believe it's simpler, but that might not be the case (it means you have to remember a code for each project, which might be counter-productive)
• Easy to find mobile app : at least it has the same commercial name. I believe it's an issue for our project to have apps with different names. I understand where it's coming from, but at some point I wonder if we should unite, create a kind of brand or something (with cospend, that is)
• Notifications : when somebody adds an expense on Tricount, you get a notification (I believe).
• Balances with graphs : You can see quickly the balance in a graphic way. It's a quick win

I also think we could do a user survey / UX survey, with people using the app in real time and us watching how they do stuff and taking notes. That would probably help us have a better ecosystem.

I wonder if you have some thoughts about this? Cheers!

[Glandos]

Accounts

I don't like them. They introduce another line in my password manager.
But people are so used to surveillance based applications that they take it for granted: creating an account is the norm.
Anyway, I have to agree that a code for each project is more complicated. So here my point of view:

• Keep project code, without account
• Add optional account
• Within an account, you can add a project, typing the code only once (or the invitation link), and then you never enter it anymore. We'll have to find out how to make this work when the code is changed.

Mobile application

I have to say that I don't have a smartphone. But the goal fulfilled by all those applications really fit the mobile usage: you enter them right after the expense, and forget. We can discuss with @eneiluj but I guess that the only acceptable solution will be to add a suffix, like a label. E.g. "MoneyBuster (IHM)" "Cospend (IHM)". As I write this, I'm not even convinced. Idea needed. Maybe an icon/color code common to every project can be more useful.

Notifications

If I understand correctly, to have notifications, you need Firebase, which is Google. Fast search leads to https://stackoverflow.com/questions/41511475/android-push-notification-without-firebase which is clearly non trivial…

Graphs

Yes, they are nice. And not so difficult to make these days, with all JS/SVG libraries. As I understood https://d3js.org/ is really made for that. Of course, it's Javascript, but I really think that it's better to generate graphs on the client rather than a static image on the server. Or generate an SVG on the server that is served?

[almet]

Thanks for your inputs :-)

Accounts

I don't like them. They introduce another line in my password manager. But people are so used to surveillance based applications that they take it for granted: creating an account is the norm. Anyway, I have to agree that a code for each project is more complicated. So here my point of view:

* Keep project code, without account
* Add optional account
* Within an account, you can add a project, typing the code only once (or the invitation link), and then you never enter it anymore. We'll have to find out how to make this work when the code is changed.

I tend to not like accounts either, but bear in mind that accounts differs from passwords.(BTW, currently, you have one line in your password manager for each project, which is even worse…).

We can have accounts without passwords, by using email as authentication for instance. I think we should list what accounts bring to the table, rather than thinking about accounts as the solution. To me, accounts are useful because :

• One doesn't have to remember multiple passwords, only the one for your account, or none at all if we go with email-auth ;
• One can list multiple projects connected to one identity ;
• One doesn't have to create passwords for each new project, thus lowering the barer to enter ;
• One could sync multiple projects at once with their phones.

To me, it seems that we could win a lot by switching to accounts in some way, and the cons are not clear cons to me. I don't like the idea to have optional accounts because it will complexify the codebase. We should decide together and keep it simple, I think :-)

Mobile application

I have to say that I don't have a smartphone. But the goal fulfilled by all those applications really fit the mobile usage: you enter them right after the expense, and forget. We can discuss with @eneiluj but I guess that the only acceptable solution will be to add a suffix, like a label. E.g. "MoneyBuster (IHM)" "Cospend (IHM)". As I write this, I'm not even convinced. Idea needed. Maybe an icon/color code common to every project can be more useful.

I think we should have IHM stay a solution by itself without the need of a smartphone. But, I also think that we should more closely integrate the two project together, for instance by scanning a QR code like it's done for money buster, in order to setup the project on a new device.

I'm not sure what we should do to make things clearer, maybe using a new name for all this galaxy of applications, which are compatible with each other. Then we could communicate on this new name, rebrand the apps with the new name. It means that we will have insert your name here for Nextcloud, for Android and standalone. I believe this would work if we find a nice name :-)

Notifications

If I understand correctly, to have notifications, you need Firebase, which is Google. Fast search leads to https://stackoverflow.com/questions/41511475/android-push-notification-without-firebase which is clearly non trivial…

Apparently you don't. You can also rely on Unified Push which provide a solution which works with multiple backends. Gotify is one of them and works without google. We could decide to integrate with Firebase notifications or not, but that seem to work from what I've read.

Graphs

Yes, they are nice. And not so difficult to make these days, with all JS/SVG libraries. As I understood https://d3js.org/ is really made for that. Of course, it's Javascript, but I really think that it's better to generate graphs on the client rather than a static image on the server. Or generate an SVG on the server that is served?

The graphs I'm thinking about are really simple bar graphs, and could easily be done with CSS and HTML. We could also integrate with JavaScript if we want more polished graphs, as proposed in #136.

In any case, I like the idea of rethinking how IHM works in our lives. Providing an easy-to-use solution which doesn't cost too much maintenance (to us, and to users) is a nice goal. Let me know what you think about my proposal on accounts, writing it made me feel that it would be a good fit. Hope you like it :-)

[almet]

Hey, here is a ping to @zorun, @Natim and @JocelynDelalande, I'm curious about what you think of this?

[Glandos]

I understand the maintenance burden of optional accounts (I really do), but I think this is both needed and not a big deal either.
When someone is creating a project, we can indeed require an account, to manage the project. But I feel that invited participants shouldn't have to be forced for an account creation, they are just here to submit new bill for their awesome socialization events. In this case, we still need a token to share for invitation links. This token could be generated instead of being user defined, but since we'll have it, we can even do the following:

• Remove access code for project creation, replacing it with a generated token, invisible for users
• When a user create a project send the invitation link via email
• If this same user has an account, link this project to the account, but as you can see, account is not mandatory here
• If a user is invited to a project, the invitation link can link this project to the account when the user is logged in

It's then possible to simplify project creation, by removing a field, and not requiring a user account. If someone creates an account after a project, it's always possible to link the project to the account.

Of course, accounts do have multiple advantages, and I clearly think we should add them. But for me, it's very important that invited people don't have to create an account to participate, and my vision on this is that it is then possible to create project with or without an account.

[azmeuk]

Hi. What about delegating the account management to an external service using a standard like OpenID Connect? This would bring accounts with a cheap cost: no need to handle passwords, re-initialization mails etc.
If that was on the roadmap I would consider submitting a PR.

[almet]

This looks interesting, but as we're going in a more "maintenance mode" for this project (see the readme) we're not considering implementing this at the moment.