Preferences

[lcreid]

We've already identified that we should preserve the state of the collapsed or expanded panels, and the currently selected fiscal year for each child. There will almost certainly be other preferences that need to be captured, and this is something that we need for almost any application.

There are options for how to remember, with their different characteristics:

• In the session, which disappears when the browser closes
• In a cookie or cookies, which apply differently on each device. Cookies require a warning in the EU if we do apps that will be accessed from Europe
• In the database, which will be the same across all devices

It's hard to predict what information will be needed for each preference, so ideally we'll use a fairly flexible format to represent the actual preference information. Given that we're working on web apps in Rails, JSON seems the obvious choice.

The other part is to define a Ruby interface to the preferences mechanism. Ideally this interface is relatively independent of the underlying implementation of persistence. Also, it would be nice to define the interface in such a way that it reduces the chance of different people using the same preference key. For example, the actual keys should be private to the class or module, so programmers have to go to that file to add new keys. This would increase the chance that they look at the old keys.

[lcreid]

A scarecrow (straw person) design:

• A single large text field (if it can be big enough) in the User table, that we populate with a JSON string representing all the preferences set for the user
• A module to manage the preferences
• Decorate the User object with the module as needed. See: https://github.com/nslocum/design-patterns-in-ruby#decorator
• To add a preference, we go to the module and add methods to set and get the preference. This forces us to look at the keys used to define the existing preferences, so they're not spread all over the code
• The hierarchy of the preferences merits a bit of thought. The preferences are for a user, by definition, but in the case of this application, many of them will also depend on the child. It would make sense internally to structure the JSON hierarchically
• The external implementation should hide the tree nature, and simply require the caller to specify the data needed to set or get the preference

[lcreid]

Of course, there are implementations out there:

• https://github.com/pluginaweek/preferences uses a very different approach for storing preferences, basically by having a column for each preference. This one's build is failing, and hasn't been touched for years
• https://github.com/huacnlee/rails-settings-cached is more like a key/value store approach. This project is missing commits from the project it's based on (the next one), but is active
• https://github.com/ledermann/rails-settings is the basis for the previous one. The project is active and said to work for Rails 5
• https://medium.com/@mscccc/rails-storing-user-settings-2016-edition-443c5ea5a921#.ynmsr35r6 looks like what I proposed in the previous comment, with some additional stuff to automate creation of new preferences

[lcreid]

@philcarrillo had a great suggestion: Keep the defaults in the database so they can easily be changed. This fits the idea that you should be able to change things without a deploy, but may break the model that all system behaviour should be tracked in git and/or your deployment pipeline, depending on how you implement it.

I'm sure there are a myriad of blog posts out there about this, but I haven't tried to track any down. The discussion shares some characteristics with feature toggles (http://martinfowler.com/articles/feature-toggles.html).

Perhaps it's worthwhile proposing some criteria for evaluating the options:

• It should be easy to add a new preference. We don't want to be coding up stuff and think, "this should be a user preference," but then we don't make it one immediately because it's too hard. "Too hard" meaning too many files to modify, or too many decisions to make, etc.
• The implementation should be relatively simple. We don't want to create a monster perfect preference gem. We just want to do what we need
• Changes to system behaviour in production can be traced via the deployment pipeline, e.g. changes are stored in Git and are pushed to an environment via an automated process
• But at the same time, preferences are likely to be the sort of thing you do A-B testing on, or that you might want to do canary deployments of, so that may or may not contradict the previous statement

[philcarrillo]

Actually, on reflection, the suggestion wasn't so great. The suggestion was that more than just defaults, but in fact, the behaviour of the 'preference' would be defined by data - as opposed to code. I think this suggestion would break far too many of the points raised above, including lack of simplicity, lack of traceability and may well be more difficult to implement.

[philcarrillo]

I have not completed anywhere near the research accomplished by the LJ Research Group - but I do get the sense that this little side track could threaten to become a major distraction and therefore I would express strong support for the criteria for evaluating options outlined above.

[philcarrillo]

It may be useful to list the present set of 'preferences', as they are fairly limited at this time.

These are:

• For each Funded Person, remember whether the panel is open or closed
• For each Funded Person, remember which fiscal year was selected in their panel
• For each user, remember if the user has been presented with the notification reminding the user that the forms are only useful for BC residents

(Note, since this comment represents the "specification" for preferences for this app, changes should be made by modifying this comment)

[philcarrillo]

Given the above immediate requirements, here are some comments:

• 'Remembering' the last selections for panel open/close and fiscal year are important within a session. We have discussed how we should try to keep the app working within the last selected fiscal year. However, it should be worth noting that it would not be totally inappropriate for these preferences to persist within a session, but not between sessions.
• The scarecrow design outlined about is a good starting, but has a fair bit of focus on the saving/retrieval of the preference. From the programmer's perspective, a nice interface would be the use of a UserPreference object which is instantiated with the current_user.id The various preferences would be methods that allow calling program to set or read the preference values. The design and implementation of the persistence of the preferences takes place within the UserPreference object. Note that the preferences of the FundedPeople need to be accessed (or set) with the provision of the funded_person_id