Node-solid-server: Existing dashboards are not regenerated after dashboard improvements

[melvincarvalho]

After improvements to the dashboard existing users will still have the existing index.html. And therefore, will not see the improvements leading to a possible inconsistent user experience.

One possible solution would be to have a link or script to regenerate templates from the original. Im sure there are other possible strategies.

Related issues : https://github.com/solid/node-solid-server/issues/683 , https://github.com/solid/node-solid-server/issues/683

[dmitrizagidulin]

Yeah, this is a tough one. We'd need to solve it on two levels:

1. Updating the New Account template (of the dashboard), so that new accounts created after a code update reflect the changes.
2. Updating each individual user's dashboard on existing accounts.

Updating Templates

Part of the design assumption behind solid-server (which may need to be re-examined) is to make it easy for server operators to customize the look of the server -- what the site front page looks like, what each new created account looks like, etc. And so that these changes persist and are not overwritten by upstream code changes in the repo.

That's why node-solid-server has a two-layer sort of structure. The default templates (new account templates, email templates) are managed by the main repo, and live in /default-templates and /default-views directories. When a server is first started up, a copy of those templates is copied into /config/templates and /config/views, and those dirs are git-ignored.
So, the contents of /config/ are for installation-specific files (such as the templates), which the server operator can modify, and won't be over-written.

So, this solves the problem of individual modifications not being over-written by server updates. But of course it instead runs into the problem of - when there's upstream fixes on the server, how do those propagate into the installation-specific templates?

There's a couple of options that I can see.

Option 1: Don't offer server operators ability to customize templates (especially while solid-server is in rapid development), so that /config/templates are symlinked directly to /default-templates, so that they automatically get updated when upgrading to a new code version. Meaning, maybe it's too early to focus on customization.

Option 2: Do nothing - leave the system as is. And document (for server operators) that when updating code, if there's any template changes, operators will either need to delete the contents of their /config dirs (so they get re-created from new templates), or they need to apply those fixes manually to their customized templates.

Option 3: Add a config option (asked during the solid init step), asking whether the operator wants to have custom templates (in which case, they'll need to proceed as outlined in Option 2), or go with the default ones (in which case, they'll act as described in Option 1). I think each config option adds confusion, but this may be the easiest option.

Updating Existing Accounts

Existing user accounts (created from account template) add another layer of complexity to this.

When a new account is created, its contents are copied from /config/templates/new-account. So that if upstream template changes are made on the server, and the contents of /config is regenerated, this won't affect existing users.

The only solution for this that I can think of is to create an external 'Check/Update Your Solid Account' app (hosted on github.io or something), that would be able to do things like create needed config options, index entries, refresh the account template (and specifically the account dashboard).

[melvincarvalho]

Thinking about this further. An auto update feature would be nice. But we also want to ensure people control their own data.

Most of our apps are client side, so maybe this is the way to go. I think the default directory structure is fine. But the index.html was added really quickly because people were saying, "Ive got an account what do I do now?".

I think in the medium a client side dash board is the way to go, where the user chooses their dash board app. But auto update in the short term to give a consistent UX and help with support, display Terms of Service etc.

[megoth]

Continuing the discussion on this, as we have had several updates to the index.html that are not reflected in PODs that were created before the updates. (Next update being https://github.com/solid/node-solid-server/issues/918).

First, to add some more options that have been discussed in other threads (I'm sorry if I'm misrepresenting the essence of the proposals):

• Add a way of opting out automatic updates
• Add a way of embedding an internal Solid file
• Adding an API that allows opt-in updating
• Serve a server-generated view if index.html is not present (I'm unable to find a discussion on this, but @justinwb mentioned it to me in chat): This might not align with the philosophy of the Solid server, but I think it fits the expectation of most (non-developer) users. In essence (as I understand it), we're saying that you can create your own index.html file to design your own experience on your POD, but if you don't we provide a generalized view that is auto-updated. I.e. handling the root of a POD for browsers will be a special case.

Right now I'm in favor of the last option (with option 2 being in a close second), but all options have the drawback that at some point we need to do _something_ if we want to include the existing users that have a POD, and I'm not certain how we want to approach that issue.

A thing about the last option is that I think it aligns nicely with the ideas that exist arounds apps and representation of PODs. But I realize this should also be part of a broader discussion on how Solid servers should handle this in general. Maybe another discussion for the Solid Community Group?

In any case, I do hope we're able find an option that we can implement for this, as I think it's hindering the possibility of bettering the UX of existing PODs.

[megoth]

After discussing with @kjetilk and @justinwb I've decided to go with the approach that @RubenVerborgh suggested in https://github.com/solid/node-solid-server/issues/936. My PR will consist of the following:

• A script that updates index.html with the latest version if meta-tag for solid-allow-automatic-updates is not set or if it's set to true (which will be the default going forward)

This means that we need to give people good time to update their index.html the first time we enable this, and a good resource for how they can do it. I'm open to suggestions on how we should do this in general, but will coordinate with the people working on solid.community and inrupt.net for how we want to do it there.

[melvincarvalho]

thanks for looking at this & +1 from me wrt solid.community

[megoth]

As there is a PR merged for this (https://github.com/solid/node-solid-server/pull/953), I hope it's ok for me to close this issue.