How to handle optional features (UI/UX and convention)

[zorun]

Historically, I think that the only optional feature was per-participant weights. We now have several additional optional features, and this is something new for ihatemoney: we may have to think how to best handle current and future ones, especially regarding consistency. This impacts the UI/UX and the way features should be integrated (enabled by default or not, always have an option in the settings...)

Here is a list of current optional features:

• per-participant weights (Add user coefficients. #94)
• history page (Add Project History Page #553)
• bill currency (Feature/currencies #541)
• external link for bills (feat: Optional field 'external link' in bill form. #479)
• pagination of the list of bills (Paginate the list of bills #480), which is not really optional but should be part of the UI discussion: it only shows up in the UI when you have at least 100 bills

And a list of work-in-progress optional features that may be merged at some point:

• split bill by amount or percentage (Split bill by amount or percentage. #471)
• recurring bills (Recurring bills (ISP, electricity, water, charges...) #152)
• tags (Add tags feature #55, added tagging functionality and filtering by date, amount, payer, tag #557)
• any work-in-progress feature I may have missed

Here are some general questions that I think we should answer:

• should the feature be part of the default UI/UX? e.g. a field in the "Add bill form", a column in the list of bills, a required setting when creating a project...
• should we be able to enable/disable the feature when creating a project?
• should we be able to enable/disable the feature in the project settings?
• how does a user find a feature if it's not visible/enabled by default?

Obviously it's difficult because these are contradictory goals (easy-to-find features while keeping a simple UI/UX).

In this respect, the way @JocelynDelalande added support for weights in #131 is a great example: it does not clutter the UI if you don't use it, but it's still visible if you are looking for it (the (x1) in the list of participants). In addition, it does not require any settings to enable/disable it.

I believe that we can make current features more consistent by answering these questions, either here or whenever a new feature is proposed: this could take the form of guidelines in the contribution documentation.

[indatwood]

Thanks for starting a discussion about this :-)

One of the reasons I like IHateMoney is that it has a clear and simple user experience. What you're proposing makes me actually wonder if we should have an optional screen to enable special features, at project creation.

Let me expand on this :

1. You create a project
2. Once this is done, you're redirected to a new page, when you're asked if you would like to enable advanced features, you can select "Yes, please" or "No, thanks, keep it simple."
3. If you select "yes", then you are directed to a page where you can enable the features.

This is kinda like the so called "first user experience" that exists on phones : the first time you start it, it asks you a set of questions to ease the use afterwards.

On a different topic, once we decided the list of questions we should ask ourselves when adding a new feature, we might want to create a new issue / pull request template to add these automatically, so that contributions are encouraged to answer these beforehand.

[zorun]

I have mixed feelings about this "first user experience" idea: it's nice because, once the project is created, it gives you an "efficient" UI that has just the options you wanted and you don't have to think about all the options.

But it deviates from the "clear and simple" principle: there are many different combinations of possible UI and feature sets, which becomes hard to test and maintain. In fact, simply having per-project settings like we do now already has this drawback. You could even say that simply adding features has this drawback :)

I guess my priority order would be this:

1. think twice before adding the new feature: will it be useful to a significant fraction of users or to just a few people? Does it interact badly with other existing features? How hard will it be to maintain in the future?
2. if the new features goes in, try to "blend" it in the UI/UX so that it is invisible if you don't need it, and it becomes visible when you are looking for it.
3. as a last resort, if it's impossible to "blend" it in the UI/UX, add an option to enable/disable it in the settings and possibly also in a "first user experience" wizard

[zorun]

And yes, once this discussion converges, we should definitely document it somewhere! The documentation and github templates look like good places.

[almet]

So, to move forward on this one, I believe we could take the easy way : features are classified between main and extra features. Extra features shouldn't be displayed to the user unless they ask for it. We could add some UX hints to show their presence.

What do you think?

[Glandos]

History can be moved in the dropdown menu at the top right then, as an extra feature.