Repository navigation
Existing dashboards are not regenerated after dashboard improvements #688
Description
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.
Activity
[-]Existing dashboards are not regenorated after dashboard improvements[/-][+]Existing dashboards are not regenerated after dashboard improvements[/+]dmitrizagidulin commentedon May 29, 2018
Yeah, this is a tough one. We'd need to solve it on two levels:
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-templatesand/default-viewsdirectories. When a server is first started up, a copy of those templates is copied into/config/templatesand/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/templatesare 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
/configdirs (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 initstep), 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/configis 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 commentedon Oct 1, 2018
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 commentedon Nov 14, 2018
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 #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):
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 commentedon Nov 15, 2018
After discussing with @kjetilk and @justinwb I've decided to go with the approach that @RubenVerborgh suggested in #936. My PR will consist of the following:
solid-allow-automatic-updatesis 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 commentedon Nov 15, 2018
thanks for looking at this & +1 from me wrt solid.community
megoth commentedon Nov 28, 2018
As there is a PR merged for this (#953), I hope it's ok for me to close this issue.