Skip to content

Provide a more information on the index page for the server itself #825

Closed
Closed
Provide a more information on the index page for the server itself#825
Assignees
megoth
Labels
UI

Description

@justinwb
justinwb
opened on Oct 2, 2018

Currently if you go to the server (e.g. https://solid.community), you get a completely vanilla index page, with no identifiable detail about the server in question. We need to expose the following (which should be unique per solid server and (probably) pulled from the config.json.

The lack of this information, especially related to who to contact for problems or issues, is leading to many people coming to the general community chat looking for help.

Server Name - Friendly name for the server - e.g. (Solid Community Provider)
Server Description - Short description of what the server is about - e.g. (A free provider for the Solid community, by the Solid community).
Server Logo - Logo file to present (if available).
Link to Project Status - Link to a page at https://solid.inrupt.com that provides a brief status of where major elements of the ecosystem and project currently stand. For example, current state of documentation against the total projected work to be done. Current state of user experience. Current state of security model. Etc.
Support Contact - What e-mail address to reach out to for help, problems, issues

Activity

  1. kjetilk commented on Oct 2, 2018

    @kjetilk
    kjetilk
    on Oct 2, 2018
    Member

    Mmmm, the support contact should be more configurable than an email address. I'd be wary of putting just support@inrupt.com in there, that could flood us in emails, better direct them towards the community.

  2. megoth commented on Oct 5, 2018

    @megoth
    megoth
    on Oct 5, 2018
    Contributor

    So a lot of this is quite easy to fix, but I think we should have a discussion on what we want to do with the front page, if anything; @justinwb and the team is working on a very good MVP for a new interface for the front page, so we might want to just wait until then. Or we might want to patch the current front page a bit, to make it a bit more useful for newcomers.

    But I suggest not doing to much, as it is going to replaced at some point anyway.

  3. megoth
    self-assigned this
    on Oct 10, 2018

  4. megoth commented on Oct 10, 2018

    @megoth
    megoth
    on Oct 10, 2018
    Contributor

    @justinwb Btw, where should we get the friendly name of the server, description, and logo? And which URLs should we use for for project status and support? (I'll try to suggest some as soon as I've worked more on this issue.)

    Should it be config-properties that POD providers can fill in manually (i.e. not as part of the solid init script) perhaps?

    @timbl (to include your requests on #844):

    • More explanation: Do we have a good text we can use here? And what do you mean with IDS? (Perhaps Identity server? Shouldn't it decentralized identity server, in that case?)
    • LINKS to help: Which URLs should we include? Perhaps https://solid.inrupt.com/docs ?
    • Links to solid: I'm guessing we should link to https://solid.mit.edu/ ?
    • Main material which the server operator can make with background pictures and styling and an explanation of what this particular community is, serves, etc, who runs it, where it hosted etc. This ties into a lot of what @justinwb suggested.

  5. dmitrizagidulin commented on Oct 10, 2018

    @dmitrizagidulin
    dmitrizagidulin
    on Oct 10, 2018
    Contributor

    @megoth The server index page is created in ensureWelcomePage() (which is called from create-app.js).

    Oh also, it looks like there's a bug in the logic there - that function only copies the index.html and its corresponding .acl, but it should be copying the whole contents of the templates.server (which is ./default-templates/server) dir into serverRootDir (which also includes things like the favicon, robots.txt, etc).

  6. timbl commented on Oct 14, 2018

    @timbl
    timbl
    on Oct 14, 2018 via email
    Contributor

  7. megoth commented on Oct 16, 2018

    @megoth
    megoth
    on Oct 16, 2018
    Contributor

    @dmitrizagidulin FYI I've fixed the bug that you noted. I had to extend the list of files to be deleted after tests, and have refactored that into a utils-method for tests. (I tried using emptyDirSync, but that created a slew of other problems =P )

  8. megoth commented on Oct 16, 2018

    @megoth
    megoth
    on Oct 16, 2018
    Contributor

    @timbl I think maybe we're talking about different things here? This is for the server info page in general, not the individual index.html in users' PODs. Or am I misunderstanding you?

  9. megoth commented on Oct 16, 2018

    @megoth
    megoth
    on Oct 16, 2018
    Contributor

    For now I'm going to work with data being provided by config.json (as that is a concept that the providers should be familiar with), but it should be easy to move it elsewhere if people think that's better.

  10. megoth commented on Oct 16, 2018

    @megoth
    megoth
    on Oct 16, 2018
    Contributor

    I might have a PR ready, but want to check in with some people first: @justinwb @dmitrizagidulin maybe you want to look at develop...feature/server-info to see if I'm going the right way on this?

    • Copy all files from default-templates/server (and modifying tests to handle this)
    • Added a section on default-templates/server/index.html that's processed by Handlebar
    • Adding server-info from config.json (is by default nothing, and will simply output host for server name if none is given)
    • Added a .gitkeep for common/img as I think a lot of people will put their logo there

    If we want to load server-info from config.json I think we should add some documentation on it, and maybe even extend the init-script.

  11. dmitrizagidulin commented on Oct 16, 2018

    @dmitrizagidulin
    dmitrizagidulin
    on Oct 16, 2018
    Contributor

    @megoth the server-info branch looks good to me.

    Although, why move the processHandlebarTemplate etc functions from account-template.js into the more generic utils?

  12. megoth commented on Oct 16, 2018

    @megoth
    megoth
    on Oct 16, 2018
    Contributor

    It was the "natural" place for me to put it, but I do admit I didn't think much before putting it there.

    Which other files would it be "natural" to put it in? Or should I've created a new file perhaps?

  13. dmitrizagidulin commented on Oct 16, 2018

    @dmitrizagidulin
    dmitrizagidulin
    on Oct 16, 2018
    Contributor

    @megoth makes sense. Yeah, maybe a new file? like a template manager or something?

  14. megoth commented on Oct 17, 2018

    @megoth
    megoth
    on Oct 17, 2018
    Contributor

    @dmitrizagidulin I've updated develop...feature/server-info; I propose we move the utils functionality into lib/common, where we would distinguish more on what util-methods we have.

    I've created lib/common/fs-utils and lib/common/template-utils for now, and we should move the functionality from lib/utils to more specific files later (didn't want to do this as part of this task).

  15. megoth commented on Oct 17, 2018

    @megoth
    megoth
    on Oct 17, 2018
    Contributor

    Apart from that, should I continue with the assumption that custom info reg the server should be in config.json? I need to know if this is the way to go before I can continue this.

    @kjetilk @RubenVerborgh @timbl

  16. RubenVerborgh commented on Oct 17, 2018

    @RubenVerborgh
    RubenVerborgh
    on Oct 17, 2018
    Contributor

    Yes.

  17. timbl
    added
    UI
    on Oct 27, 2018

  18. michielbdejong commented on Jun 20, 2019

    @michielbdejong
    michielbdejong
    on Jun 20, 2019
    Member

    @kjetilk can this be closed?

  19. kjetilk commented on Jun 21, 2019

    @kjetilk
    kjetilk
    on Jun 21, 2019
    Member

    I think so.

  20. kjetilk
    closed this as completedon Jun 21, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

UI

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions