I would say to show a button/ dialog that suggests you to search on the provider overview page.
Also we could provide a stripped doen version of the provider list with each release:
Config/Login Fails -> provider is in this list known to not work out of the box -> show link to provider overview (page that contains the steps)
I do not know… This does not sound very userfriendly to me. I’m afraid that quite some users will quit if you point them to a website and tell them “Go look for help there”. At least I would, if I didn’t hate WhatsApp so much.
A support bot can then lookup there the users provider that asks for help.
Maybe I misunderstood you but - the user can’t chat with a bot if they could not login.
And again, I am willing to help with this and send a PR.
Ok, that’s a point (although probably most users await that a chat app will connect to a server, even without asking). Another idea: Bundle the overview with DC as an asset (the _providers folder is less than 150 KB).
Shipping the “problem–>solution” info (only for providers with actual problems) actually allows to avoid errors, by displaying the info in the configuration dialog for the known providers even before making a connection attempt.
And it allows the app to be usable with just email connectivity (firewall).
The Provider overview is made with jekyll - a static website generator, I think I can add a site/endpoint that combinds/generates this data, so the release update/script only had to pull some file like https://providers.delta.chat/setupinfo.json or rather .xml?
Anyways lets talk about formats and structure then I can add a page like that.
I also still need to ask @hpk what he thinks domain-wise and then we can put up the (alpha) provider overview.
Is http://providers.delta.chat/data.xml ok/enough to work with?
We still think about moving the needs preparation column to status so this isn’t the final format.
The Liquid Template language is limited, so html cleanup would be have to be done manually.
The update script for dcc-rs would need to fetch the document and (optionally) minify it to safe space. I choose xml as format because we’ll have a xml parser in dcc-rs anyway (https://github.com/deltachat/deltachat-core-rust/issues/47).
A note on http://providers.delta.chat - The site is still in an early state so please don’t do big announcements until it looks presentable.
Looks good, thanks! What I just noticed when I looked at data.xml: XML is a format that has a lot of “redundant” characters, maybe this could be fixed by making the tags shorter (<pr> instead of <provider>); either in the original xml file or when it is put into dcc-rs. Or we choose a very simple format like
provider2.net:Preparations for provider2
and a simple list for providers that do not work at all (works=false). Any opinions?
Is data.xml going to be the new “source” or is it generated somehow as well?
And what language can the update script be in? Bash?