How should we handle data syncing?

[esgoodman]

Background

MyUSA is supposed to help people customize online interactions while avoiding lots of repetitious form-filling. Users provide or edit personal data in the process of signing into a new website or application.

So the user is likely enter data that is meaningful within the context of that application (e.g. if a woman uses a birth last name professionally but her spouse's last name in personal life).

When a user hits another application that uses the same data, the user has the choice to edit the data that the application is getting (e.g. changing birth name to married name or vice versa).

What happens then?

There are three ways integrators can use authorized MyUSA data.

1. Request always MyUSA stores the data and the integrator requests it every time the user signs in.
2. Request sometimes Integrator stores the data but periodically checks it against the MyUSA profile
3. Request never Integrator stores MyUSA data during first sign-in and never pulls it again

   Two scenarios

Let's say a user first enters the married name into a MyUSA account related to personal/home life, then edits the name at a permissions screen later to use the birth name for a site related to business activities.

Case 1: Stable relationships but different names

The user wants this specific application to use the business name, assuming that other applications will still use the home name saved in the MyUSA account management site.

As a result, the next time the user signs into a request always application, the user may be surprised by an inappropriate name. How does the user change this inappropriate name?

Request sometimes applications will use the home name for an unspecified period, then suddenly change the last name seemingly without a cause.

Request never applications will behave as the user expects...but the user will not know why some applications "work" and some do not.

Case 2: Changing relationships, changing names

The user gets divorced and wants all applications to use the birth name. The user changes the last name in the account management site, assuming that the birth name will automatically propagate to existing applications.

As a result, the next time the user signs into a request always application, the user gets what was expected: the new (old) name.

When the user signs into a request sometimes application, if s/he is lucky s/he will find that the application has updated the last name field. If the application has not refreshed its profile data in the intervening time, the user will see a last name that is an infuriating or depressing reminder of a changed situation.

Request never applications will drive the user crazy if there's no way to edit the last name locally and the user is stuck seeing an inappropriate name every time s/he logs in.

The problem

MyUSA's potential behavior in the first case violates of the put personal data in context of relationships principle. We are mixing together contexts that users have told us (by changing the last name) they are trying to keep separate. And, following a more general design principle, they won't be able to tell why some application behave as they expect and some do not. Ugh.

Furthermore, we deal with a lot more data than last names: marital status, parental status, and so on. All of those are, for better or for much worse, subject to change. If MyUSA is going to be useful to people in the long term, they need to be able to make sure the data is accurate. If we want to make consent meaningful, we need people to be aware of how that data is being synced and (potentially) be able to control it.

[esgoodman]

As per conversation with @yozlet, Case 1 is really much less urgent than Case 2. It makes sense to characterize this issue as a question of how we make sure

• RPs' data are up to date
• Users' mental model of data sharing matches what's actually happening

[esgoodman]

One solution to keeping distributed data up-to-date, as per @yozlet: hooks

[esgoodman]

Another solution: manual syncing

[esgoodman]

@yozlet Just how technically complicated would the hooks option be?

Conceptually, if we say that MyUSA is "one account for government," then we should genuinely provide one central account. I'm convinced by the argument that having two separate accounts under two different email addresses deals with Case 1, and that Case 2 is the real test of the "one account for government" promise.

That means making sure changes to data in MyUSA in one place propogate to partners. As per Tesler's Law of Complexity, we can either delegate that job to users and developers, or deal with the complexity of syncing data ourselves. The latter seems like the option most likely to be successful, and the most in keeping with what we have promised everyone MyUSA will do.

(h/t to @noahmanger for bringing some clarity to my thinking on this.)

[mkhandekar]

@esgoodman, thank you so much for writing this out, very helpful.

1. Integrators & MyUSA data Do we have any control over the three ways integrators use MyUSA data? It would be helpful for integrators who never request (no. 3) data to be informed that MyUSA allows people to update their data and that they'd be missing out on current data. When integrators reach the point of deciding how to use MyUSA data, seems like a good opportunity for us to inform / educate integrators the pros & cons of the three ways of syncing.

2. Manual syncing vs Hooks Manual syncing seems to me like using hooks, but on delay. I can imagine that people might forget to force sync their data on the account management site, and be confused / frustrated when their data is not what they expect on partner sites. At the same time, a lot can be done from our end to remind and help visitors in this process, if we choose this route.

What is the main benefit of manual syncing for visitors? The feeling of complete control of when their data gets sent over to partner sites? My hunch is that using hooks (automatic syncing) seems to take that burden off of the visitor completely, and we'd want it to be as simple as possible for them.

[esgoodman]

1. I'm wondering if we just shouldn't make integrators refresh their data on every new login. That would take care of the profile-updating inconsistency that irritated and surprised participants in the account management site study. They were irritated and surprised because they changed their name in the MyUSA central profile, then discovered when they logged into OpenOpportunities that the name was unchanged.

2 Agreed. My guess is that automatic syncing, as with 1, simplifies the MyUSA model considerably for everyone, visitors, integrators, and us alike.

[esgoodman]

...With the proviso that we inform users that updating on the permissions page will change the internal site